Ubuntu, because I don't want to think about the OS too much. I expect that I'll someday try out more distros either to get away from snap or to get faster updates for different fractional scaling on multiple monitors.
50 karma · joined June 23, 2015
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
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.
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.
It was extra special because I work in nlp but so many nlp applications just don't excite me
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.
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.
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'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.