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.

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

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.

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

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.

- 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.

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 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/

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

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

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.

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

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.

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.