The junior and the agent

A colleague eight months into their first job fixed a caching bug in about 40 minutes. At eight months I would not have fixed it. I’d have escalated it after two days, and somebody would have fixed it in front of me while I watched.

The fix was correct. It was better than my fix would have been. Then I asked why the invalidation had to happen in that order and they said, entirely without defensiveness, that they weren’t sure, that’s what it suggested and the tests went green.

Which is a completely reasonable answer from somebody eight months in, and I want to be careful, because the version of this post where I’m disappointed in a junior developer is a bad post and also not what I think. They did the job. The job got done.

I’ve been chewing on it for two months and I’m still not comfortable, so I’m going to write it out and see where it lands.

What being stuck was actually doing

Here’s my honest account of how I learned anything, and it’s not flattering.

I learned by being wrong in a way that cost me something. Not by reading, not by being told, and largely not by being shown. By forming a wrong idea about how the system worked, acting on it, watching it fail in a way the wrong idea couldn’t explain, and having to go and repair the idea.

That process is expensive and slow and it is the thing that builds the model. Every useful intuition I have about caching, or specificity, or why a form breaks on a phone and not on a laptop, came out of some afternoon where I was wrong for long enough to have to account for it.

An agent removes the afternoon.

But most of the afternoons were waste

And here’s the counterargument I have to make honestly, because the romantic version of the above is a lie told by survivors.

An enormous proportion of what I was stuck on was not educational in any sense. It was a misspelled property. A version mismatch. A tutorial written for a release two behind the one I’d installed. A trailing slash. I once lost the better part of two days to a character encoding problem and I learned precisely nothing from it that I have ever used again, and I am not nostalgic about those two days.

So “struggle builds expertise” is too coarse. Being stuck on “I don’t understand what this system is doing” is where the learning is. Being stuck on “I have made a small mechanical error and cannot see it” is pure loss, and there was a great deal more of the second kind than the first.

Agents are outstanding at deleting the second kind. That’s an unambiguous gain and it is most of what I get from them personally.

They also delete the first kind, and that’s where the problem is, and the two feel identical from the inside while you’re doing it. You cannot tell, at the moment of asking, which sort of stuck you were about to be.

You can't tell, at the moment you ask, whether you were about to waste an afternoon or build the only thing that would have made you good at this.

The calculator, and the one place it breaks

The obvious rebuttal, and I’ve had it put to me twice, is the calculator. Nobody does long division by hand any more and civilization is fine. Nobody hand-writes assembly. I’ve never implemented a sort. Every generation offloads something and the previous generation frets about it and is wrong.

I take that seriously, and I was on the receiving end of it. People said Stack Overflow would produce a generation who couldn’t reason from first principles. I learned a substantial amount from Stack Overflow. I think I’m alright.

But there’s one asymmetry that I can’t argue away.

A calculator is never wrong. The offloaded skill is not needed to check the offloaded work, because there’s nothing to check. Long division is safe to lose because arithmetic has a verifiable answer that arrives correct every time.

An agent is confidently wrong on a regular basis, and detecting that requires exactly the model that would have been built by doing the work yourself. The skill you’re skipping is the skill required to supervise the thing you’re skipping it with. That’s not true of calculators and it wasn’t quite true of Stack Overflow either, because finding the right answer there meant reading four wrong ones, and choosing between them was itself the exercise.

Degree rather than kind, maybe. But the degree has got very large.

Which is the same trap, industrialized

I wrote something in 2021 about tutorials, and the phrase I used was competence you borrow and hand back: everything works while you’re following along, nothing goes wrong, and then you sit in front of an empty folder and can’t start.

This is the same shape with the loan extended indefinitely. The borrowed competence doesn’t get handed back at the end of the chapter now. It’s available every day forever, which means you may never find out what you’d have been able to do without it, which is a strange thing to say about a person’s own abilities.

I don’t know how to feel about that. The tutorial version was clearly bad because the loan was called in. If it’s never called in, is it a loan?

The bit that actually worries me

Not any individual, and not the eight-months colleague, who is quick and careful and will be extremely good.

Seniors exist because they were juniors who did work that is now cheaper to not do. The pipeline that produces people who can tell whether generated code is right runs entirely on people spending years being slow and wrong about code they wrote themselves.

Nobody owns that pipeline. Every individual firm is correct, in isolation, to take the faster path, because the cost of not training anybody lands somewhere else entirely, years later, spread across an industry. It’s an externality with a ten-year lag, and nothing about how our work is organized is capable of pricing that in.

I’d like to say the market will sort it out. My honest expectation is that it will sort it out around 2035, by which point the people who could have taught the judgment have left, and everybody will describe it as a skills shortage that came out of nowhere.

What I’ve changed, which isn’t much

I’m not going to tell anybody not to use these things. It would be hypocritical, since I use them every day, and it would be futile, since they’d use them anyway and just not mention it, which is worse than doing it in the open.

Two things, both small.

Before, I ask what they’d have tried. Not as a test and not before every task, but often enough that the habit of forming a hypothesis first stays alive. That’s the bit I think is genuinely important, and it survives the tooling.

After, I ask why it’s like that, and I want an answer. Not to catch anybody out. But “I don’t know, it suggested it and the tests passed” is a fine answer at eight months and it can’t still be the answer at three years, and the only way it stops being the answer is if somebody keeps asking the question.

The standard I’ve landed on, which I’ve said out loud to the team so it isn’t a secret rule: use whatever you like to produce it, and don’t hand over anything you couldn’t defend if the person receiving it asked you one hard question about it. That’s not new. It’s what code review was always supposed to be. It just used to be satisfied automatically, because you’d typed the thing.

From the wrong end of it

The caching fix went in and it was right and it’s still right.

And I’ve been a junior in a period when everybody senior was certain the new thing would ruin us, and they were wrong, and I remember how it felt to be told that the way I was learning didn’t count. And I’m describing a mechanism I can only observe from the wrong end of, about an industry two years into a change that will take 20 to show up.

If you’re eight months in and reading this: you’re not doing it wrong. Just ask yourself why it’s like that occasionally, before somebody else has to 😬