munchbunny

As a hiring manager and a manager of engineers across the seniority spectrum… yeah, I think these traits now matter more than raw coding skill. They always did at senior levels, but now juniors need to start picking that up sooner because the ability to get code through the system is no longer a common bottleneck. Now matters of taste are far more obvious, and consequential.

The ability to understand the interactions between systems still matters a lot. Unfortunately AI does hit walls, and how well you can handle when it does is a big productivity differentiator. I consider myself lucky to have paid my dues well before coding agents entered the picture, and I feel for the people who are only just now entering at ground level because we really have no idea how to teach our discipline anymore.

I suspect this VBO will see a lower acceptance rate because there will be a lot of eligible people in their early or mid careers, and unless you are one of the people who won't have trouble finding a new role, or you expect to be fired/laid off soon, or you're are already on your way out, you probably don't want to be starting the job search right now.

For my case (modding games), yes, a big part of my reason for doing it vs. any other software project is experiencing others enjoying my work.

I also have projects I make for myself for personal practical reasons. In those cases very little has changed, because whether or not I use AI only affects me.

I will corroborate that AI and pressure even in hobby spaces (like game modding) to ship faster if only to preempt a crappier implementation from gaining traction is making it harder to feel motivated to make something because there’s no time to also enjoy the technical puzzle or to really pay attention to excellence in the details.

I’m not really lamenting a bygone era, just saying that the feeling of programming for a hobby has also changed and the parts that are fun don’t line up as well anymore, so I do less of it now.

> Some may consider it extreme, but, in my view, in an ideal world, people would treat testing in animals almost like testing in humans.

I don't consider it an extreme view, as lots of people share that view. But within the scope of pharmaceuticals, as opposed to cosmetics, I disagree with it because I think that's an impractical guideline to follow. Animal testing happens because there aren't good alternative ways to get safety data (on a per-treatment basis) without putting human lives at risk, and it's already a tiered system designed to balance scientific need against animal welfare. This is also why in standard medical trials proving safety comes before proving efficacy.

> The researcher should first ask "would I feel comfortable testing this in a voluntary human test subject?" Non-human animals would still be the first line of testing, since harm/death in a rat/mouse/chimpanzee is less morally bad than in a human, but I think this should be the mindset.

The problem is: how do you as a researcher become comfortable testing on a voluntary human test subject? You need safety data. How do you get the safety data? Right now, the main way is a tiered system that starts on a petri dish and eventually passes through mice, monkeys, etc. before humans.

> The kind of expectations I have is that people do their best and I expect people to understand what they are doing.

> But that understanding has very little to do with what tools they use.

> And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.

He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking.

But to pull something from the post:

> If this is the right mental model, you should expect to see:

> An unusual amount of in-house harness building on both the build side and the sell side

Yup.

> Org structures and individual roles being reshaped around their place in the business harness

Not yet, this is the one I am most skeptical about because it's still way too easy for the harness-driven processes I've seen to go off the rails, so it's still very much human SME-driven. However, the number of butts in seats required is going down.

> AI-native startups beating incumbents in domains where the “moat” can be easily harness-ified

In most cases I've seen the "moat" is not easily harness-ified, and increasingly the money and energy seems to be going into getting to the starting line.

> All software a software company uses (on or tied to the core build or sell paths) needing to be headless so the outer harness can run it

Tech companies are definitely doing it, but I don't think this is actually realistic yet for companies whose core competence isn't software. But this feels like a matter of when, not if.

It's also more fun on a server with friends, where it can be more about hanging out and doing something together, rather than a solo creative exercise.

From my experiences using AI to write documentation, if your bar is high quality documentation, yes, you do save time, but it's on the order of a 1.5-2x efficiency boost, not 10x. The AI basically saves me one draft iteration and saves me the trouble of creating charts by hand, and that's substantial, but I still need to take a fine toothed comb to the output.

The biggest issue I run into is that AI is good at the tone to address an intended audience but is not good at framing and structuring the information for said audience.

My experience with AI-written documentation is that, as a category, it contains just enough technical errors that more often than not I end up spending time running down confidently stated errors the old fashioned way: cross-referencing API documentation, reading code, etc. At that point you inevitably end up trying to get in touch with a human from the other team.

In other words, it's not because I don't know it's there, or I don't want to read it, it's because my priors tell me it's going to waste my time. What I end up doing is searching, finding the docs, and reading until I start to get the feeling of hallucinated factual errors.

I'm sure there's AI-written documentation in there where the authors really did a good job reviewing it, and I just didn't notice. But I've also had engineers under me lose weeks of productivity at this point because of documentation confidently presented, insufficiently vetted, that turned out to be wrong.

But the canonical way to do it that is both free and infinitely customizable is to host your own server. It’s pretty straightforward to do these days. However, before you do, I would suggest playing the game a bit to understand what the settings are/mean. You and your kids could play together a bit on a Realms server or a community/public server to get a feel for what you want in a custom server.

I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.

I prefer to interpret it charitably: the line between influence and manipulation can be pretty fuzzy, and some people come to a conclusion of, basically, "don't do it at all because it's always selfish."

I think it's a flawed view because it's impossible to go through life not influencing anyone and not wanting anything from anyone, so you may as well try to do it in a way that is generally win-win or at least not win-lose.

It's two sides of the same coin. Many techniques in that book are things that both genuinely kind people and manipulators do, the difference is intent. In that sense the idea of the book is a bit of a Rorschach test, although the way the author goes about it makes it pretty clear it wasn't meant to teach manipulation.

When I read the book over a decade ago, it did not feel like a red pilled book, it felt like a guide for well-intentioned people to learn how to express that more effectively. On the spectrum between "people orientation" and "task orientation", I was a task oriented person learning how to navigate personal and professional relationships more like a well-adjusted person would, and I suspect I and everyone around me was happier for it.

Every baby is different so most of the advice you find won’t work, but if you try enough things you’ll eventually find something that works consistently. Or you might just luck out and get a good sleeper.

For sure, probably because stinky diapers are visceral but psychological challenges aren’t, yet I think most parents would agree about having to dig far deeper into our inner resolve to deal with age-appropriate behavioral issues.

If you think about the people in your team who command the respect and trust to be able to get past all of that wariness of team outsiders, it's usually a really small number of people, and usually they are veterans who've been around for long enough to have built those relationships.

At least today the coding agents will cheat, choose the wrong pattern, brute force a solution where an abstraction or extra system was needed, etc. A few PR's won't make this a problem, but after not very long at all in a repo that a dev team is constantly contributing to (via their herds of agents) it can get pretty gnarly, and suddenly it looks like the agents are struggling with tech debt.

Maybe one day we can stop writing programming languages. It's a thought-provoking idea, but in practice I don't think we're there yet.

I think a lot of people miss this point.

Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.

Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.

In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).

TL;DR: not enough training.

As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.

I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.

Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.

Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.

If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.

The general way to handle this as an interviewer is really simple: acknowledge that the interviewee gave a good answer, but ask that for the purposes of evaluating their technical design skills that you'd like for them to design a new system/code a new implementation to solve this problem.

If the candidate isn't willing to suspend disbelief for the exercise, then you can consider that alongside all of the other signals your interviewer team gets about the candidate. I generally take it as a negative signal, not because I need conformance, but because I need someone who can work through honest technical disagreements.

As a candidate, what's worked for me before was to ask the interviewer if they'd prefer that I pretend ____ doesn't exist and come up with a new design, but it makes me question whether I want to join that team. IMO it's the systems design equivalent of the interviewer arguing with you about your valid algorithm because it's not the one the interviewer expects.

As a former PM (now an engineer), I think that's pretty much it. Teams and companies will vary a lot in terms of what they want the PM's to do, with some common patterns emerging, but as long as the PM's do the work well then the team is much better off. The key issue is how much you can trust the PM to hold up their end of the project.

A common theme I've noticed among good PM's: good judgement. When the team can trust the PM's judgement, the whole team flows better. When the team can't trust the PM's judgement, the PM is worth negative bandwidth.