ktrnka

I struggle with terminology so I made a little Gnome utility for easier LLM-based terminology lookups from a highlighted word/term + contextual screenshot. So far it's working pretty well, kinda like a better version of the Mac OS or Kindle ones.

It traces back to accessibility. Think of folks with shaky hands. The screen helps to stabilize the tremors. A similar thing applies to typing on a bumpy bus or while walking.

That said, it also depends on screen size. Back when Swype first became popular, Android screen sizes ranged from 3-5". That was another factor driving it's popularity back in the day.

Definitely not for everyone or in every situation though

I don't have a lawn, but I could use some more software around native habitat restoration for Green Seattle work parties. I end up using Claude or ChatGPT for plant identification because iNaturalist isn't as good, then getting the background on each plant - native? non-native? invasive?

When I'm planting, site selection is important but I'm really slow at it, even when using AI.

I also use AI for some plant diagnosis but that hasn't led to any meaningful action, except that I'll be more thoughtful about site selection for some plants in the future.

Most of this could just be a collection of documents in a Claude project, but hey if more people are working on it I'm all for that even if there are competing tools.

I like the formatting and readability of https://nesbitt.io/2026/05/28/protestware-for-coding-agents.... though I wish it loaded faster.

I found it was a slow read in parts, but it was time well spent. There are deep themes that run through the whole letter and provide much better context for the quotes I've seen in the news. I'd also add that while the letter does offer feedback for the tech industry, the main focus felt like a more positive vision of what the future could be (if countless people work towards it).

Love the idea. The ability to PR a dashboard would've helped us in multiple companies.

The two big areas that could use some docs/work: - Auth (one company was healthtech, so we needed auth even on VPN. The other didn't have a VPN so we needed auth) - Hosting: If it just needs to be run in a container and it doesn't need to be restarted that's fine. Though if there isn't a hosting document it's often a sign of a service that will need someone to keep it running all the time

I'm a few years behind you. I got started on my uncle's handed down vic 20 in the late 80s.

The culture change in tech has been the toughest part for me. I miss the combination of curiosity, optimism, creativity, and even the chaos that came with it. Nowadays it's much harder to find organizations like that.

Looks good to me! The status bar did something weird on my codebase in which 2% was really 100% so it looked like it was gonna take hours but only took a minute or so.

I'll try hooking it into my refactor/cleanup workflow with copilot and see how it works as grounding.

Yes. Earlier in careers, passion can lead to more time and energy towards growth, which is a strong contributor to becoming a great engineer.

For more experienced engineers, I think about it as skill vs motivation. In theory one doesn't need motivation to do great work. In practice, I haven't seen great work from folks with high skill but low motivation.

A couple fun ones I remember taking:

- Recently: Given some basic intermediate output from LLM system, build out evaluation/quality tools, especially for dealing with hallucination - ~8 years ago: Given a database table of restaurants, identify near-duplicates to merge

On the hiring manager side of things, my candidates generally enjoyed doing a take-home to build a ML model for the Li & Roth question classification dataset. That involved a bit more creativity and it was very role-related.

After being on both sides of the interview process, my current feeling is that take-homes are a decent fit for junior roles but take-homes are not a good use of time (on either side) for senior roles.

I worked on a hackathon project to update readmes based on PRs, and it feels very doable. The developer experience is the hardest part... we did a Github Action that would open a PR for README changes, but it's a little slow to edit the PR if any changes are needed and it feels uncomfortable to put API keys into a Github Action.

If you're curious, I've been updating it a little since the hackathon: https://github.com/ktrnka/update-your-readme The readme was mostly generated by the tool itself as we did PRs to build it.

I like to research companies that I'm interviewing with and I've been automating my process lately. It's also been a good opportunity to explore many of the challenges in LLM/RAG applications like user trust, dealing with bias in the information sources, and static vs dynamic graphs.

I was partly motivated by seeing so many good people go through layoffs :( Here's the work in progress if it'd help anyone: https://ktrnka.github.io/company-detective/

Please do! That sounds super interesting

Looks good so far! If it helps, some of the challenges I had with take-homes as a hiring manager were: - We'd suggest to spend an afternoon on it, no more than 4 hours, but many candidates would go far beyond that - Senior candidates tend to have less free time to do take-home assignments. Some would decline to do them and others would have to delay their interview pipeline for weeks (and by then, many candidates had lost interest or progressed with other employers)

That said, take-home assignments were very helpful for junior candidates who didn't have much experience on their resume.

Textgrad mainly optimizes the prompt but does not inject few shot examples. Dspy mainly optimizes the few shot examples.

At least that's my understanding from reading the textgrad paper recently.

I'm wrapping up my current sabbatical, and I took one before.

In the first sabbatical, I left my job to work on a startup idea with friends, and I learned a ton from it, both technical and non technical. I did lots of side projects I'd wanted to do for a while when that flopped, which led me to learn some more technical skills I later used. I also hiked a lot more which was great. After maybe a year and a half I returned to the workforce because I missed working with people and my savings were dwindling.

In the current one, I left my job without much of a plan. I spent more time with friends and family, traveled a bit, mentored a bit, did some side projects, read more, and learned more. This time around I found I missed working with people sooner.

In both cases it was expensive but worth it. The most valuable parts were being more myself, spending time with people, and learning things I wouldn't normally.

If I remember right, my team's pipelines took about 40-60 min on average. We deployed machine learning models and code to lambda via cdk. The things that made it slow were having to deploy dev staging and prod with no resource sharing between them, docker builds and uploads, and end to end tests.

I made a similar change in my last role and it was a great experience. The big difference is that I took about 30 minutes and also asked a bit about work on their resume to check basic things like whether their work had actually been deployed and used, awareness of user impact, double checking technical experience, etc.

The biggest benefit of taking more ownership of your own hiring pipelines is that you can use the results of each stage to improve the others. If many fail the formal tech assessment, you can dive into more tech in the screen or adjust the minimum qualifications. If candidates are rude in the full loop, you can check for that earlier. Or if most candidates pass the full loop, you can loosen up on earlier stages or reduce the loop

Funny enough I was in this situation a few weeks ago. My old resume was in latex with moderncv and I decided to make the new resume with Creddle after seeing it recommended. Now I'm back to latex with moderncv. Creddle was just too slow and using a markup language is more flexible.

Also I'm happy to help any way I can. I'm not sure the best practices of sharing contact info on HN but if you Google K Trnka language modeling I should be the only one

I'd suggest starting with just building a high quality data set with text from a variety of domains, and starting off by publishing that. Maybe even developing some related tech like adding the dialect to language id packages. Another key thing might be to build a nicely curated word list for the dialect, and make sure there's good documentation for researchers wanting to work in the language.

Partly I'm feeling inspired by Google's machine translation paper about scaling to the next hundred or thousand languages. Some links in here https://ai.googleblog.com/2023/01/google-research-2022-beyon...

But also when it's been successful, it's an effort of many different researchers. And it usually starts with data.

Training a language model on top of it is definitely doable even for individuals, you just might not be able to train on a huge data set or you might hit a wall in terms of the perplexity you can reasonably train.

What is tech debt, really?

It's gotta meet two criteria for me: 1) code that's unusually hard to maintain or extend that 2) could've been designed much better initially. So "uses a weird library" wouldn't necessarily qualify unless it's very cumbersome. "Uses a weird language" qualifies if there aren't many employees that know the language. If it's a situation in which the code could be better, but the current needs of the code were not knowable at the time of authoring, I wouldn't call that tech debt.

I don't like to talk about "good code" or "bad code". It's rarely grounded in evidence, and more often a sneaky way to say "it makes sense to me personally". Maintenance cost isn't easy to quantify but it's a step in the right direction.

Is the phrase tech debt being misappropriated to justify rewrites?

This seems to focus on the terminology aspect more than the underlying problem -- many engineers are just more enthusiastic about new code, and some will make up whatever argument they need to spend their time on new code rather than old. So if it weren't a misuse of terminology, it'd be a misuse of something else.

I'd suggest asking people to quantify it at least a little -- could someone estimate project completion with/without a refactor to get a general sense? When I've asked my people to do that it helps us talk about whether it's worth X months to save Y% * Z features.

My experience in Seattle is that the majority of my coworkers have more free time and less stress as a result of WFH. I enjoy going to the office and having a feeling of community, but I'm in the minority, at least at my former employer.

Over time I'm hoping the workforce will redistribute somewhat so that more office folks join the same pro office companies. For myself I'd prefer to join a company that has some office community even if it's a hybrid company.

Descript for podcast editing. I used it for an internal podcast last year and got to experience childlike glee once more.

It was extra special because I work in nlp but so many nlp applications just don't excite me

Thank you for this. It puts words to a situation I made worse with a report a few years ago and helped me see it another way

Positive experiences - Patent lawyers at one company were just plain easy to work with, and took the time to explain why they were filing the patent a certain way. They didn't put too much burden on the inventors. Overall it wasn't much effort for me and my coworkers and I understood what was happening. I think they were company-internal lawyers - Having a contract lawyer review a basic contract for software development was a good experience - they were quick, professional, and responsive. I remember being uncomfortable doing remote contract review at the time (around 2015) and it's funny how the times have changed - Being prepared for a deposition was a good experience and they took the time to teach me a lot about how to disagree in a cooperative manner - Chatting with a contract lawyer about delays in signing deals was always useful and taught me a lot

Negative experiences - Patient lawyer consultant at another company was just ok, they put the burden of strategy on us and any time we asked for advice they would flip things around and ask what we wanted to do, but high-level direction wasn't enough for them - Legal team inside a previous company would swoop in out of nowhere and raise a stink about every little thing. When we included them early on projects, they'd take it as a sign to try and meddle with every little detail and often delayed projects or led to them being shelved indefinitely. It would've gone a lot better if they just spent time to make sure we were informed about legal risks enough to make tradeoffs, but they were pretty heavy handed. In later years it got worse when they started to step on PMs and other leaders toes about overall feature designs and product designs. Like things that didn't have legal implications at all.

I once froze a subset of the training data and used it in the test suite for the training pipeline. It was pretty handy as a quick test while refactoring. I don't think I got it integrated into our Jenkins pipeline so it wasn't used by the rest of the team and eventually got outdated as the training data changed.

We didn't do the "at least as good" thing though. In prior jobs I'd seen too many legitimate situations in which a metric declines even though there's no regression, such as bug fixes in metrics or occasional updates to the test data. Instead we committed the model evaluation to git and had to review and approve model updates.

I wish we'd done more testing for that pipeline, particularly the parts that fetched and preprocessed data. I think we had a couple bugs there over the years, or partial missing data.

Causal inference, or any similar way of controlling for confounders, particularly for features that are launched at a point in time for the whole population rather than an AB test.

Summarization of open ended feedback, or more generally just making sure there's both measured data and feedback data

Cohorts analysis

Identification of both high and low adoption users to interview each group

I'm a big fan of having people discuss designs before implementation. That said, I'm not much more formal than nudging folks to have a discussion with their peers. It could be a meeting like you mention, or just an informal chat over coffee.

I've seen too much harm come from overly prescriptive approaches to design review, which I've seen lead to people resisting, and that might be going on with your team too.

I saw it decline over the last year at my employer. In 2021, the recruiting team and I were all on the same page about letting candidates know the decision within a day either way. In 2022 there was some desire to do that, but the recruiting team lost their most senior people and became very understaffed for a while, so it often took a while to get notice sent.

In 2021 my recruiting partners were cool with me moving candidates through stages, which triggered automated notification emails for the candidates. In 2022 I didn't have the permissions for that. Not sure how that all happened, but there was definitely a lack of an ATS admin of some sort.