The Junior Developer Problem

Nobody lets you fly the big plane first.

You start in something small and slow with a lot of duct tape on it, and you do the same circuit over and over. Take off, fly a rectangle, land, do it again. It's boring. It is meant to be boring. Somewhere around the two hundredth landing your hands start doing things before your brain has finished the sentence, and that's the point. That's what the hours were for.

Software had a version of this. It was called being a junior developer, and it consisted mostly of CRUD.

Your first job was forms and endpoints and list views and the migration nobody wanted. Nobody framed it as training. It was framed as the work you were allowed to do because you couldn't be trusted with the other work yet. But it was training. That's where you learned that the database doesn't care about your feelings. That's where you found out what happens when two people edit the same record. That's where you built the fourth list view and finally understood why the third one was wrong.

We just took that away.

Not on purpose. Nobody sat down and decided to remove the on-ramp. We built a machine that does the on-ramp work in forty minutes and then, quite reasonably, stopped assigning it to humans. The highway's still there. The on-ramp is gone. And I'm not sure anyone's fully clocked what that means for the person who just graduated.

I'll say up front: I do not have this figured out. This is the post in the series I'm least sure about and most bothered by. Let's get into it.

Where intuition actually came from

I wrote a post a while back about legacy code, and the argument was that wrestling with ugly systems is how you learn the business. Nobody explains the weird logic in the billing module to you. You find it at 11pm, you swear at whoever wrote it, and then you understand it in a way no document could have given you.

Here's the thing I didn't say in that post because it seemed too obvious: that only works if you're the one doing the wrestling.

Engineering intuition is not knowledge. It's scar tissue. It comes from having been wrong in a specific way enough times that your gut flinches before your reasoning catches up. You can't read your way into it. You can't watch someone else acquire it. And you definitely can't get it from reviewing code you didn't write, produced by a tool that never hesitates.

The senior developers on your team have this. They got it the slow way, by being juniors when being a junior meant grinding. That grind is now optional. Which means the next generation of seniors has to get their scar tissue from somewhere else, and I don't think we've built the somewhere else yet.

The two lazy answers

Whenever this comes up, one of two things gets said, usually with some confidence.

The first is "juniors will just learn faster now." Maybe. They can certainly produce faster. But producing and learning aren't the same thing, and the gap between them is exactly the problem. A junior with a good AI tool can ship a working feature on day two. They cannot tell you whether it's a good feature, whether the approach will hold up, or which of the six things the tool did are load bearing. They've skipped to the answer without doing the problem set. That's not learning faster. That's not learning.

The second is "we just won't hire juniors." This one gets said quietly, in leadership meetings, by people who are being pragmatic. And in the short term it works. Hire seniors, let them use the tools, ship a lot.

Then wait ten years and try to hire a senior. Where do you think they come from.

Every company that stops hiring juniors is making a bet that someone else will train them. If everyone makes that bet at once, the industry has a pipeline problem that shows up right around the time the current seniors start retiring to go fly small planes. This is not a hypothetical. It's a spreadsheet.

What it's actually like right now

Put yourself in the seat.

You're a year out of school. You've got a tool that produces confident, working, well formatted code for basically anything you describe. Your job is to review it and decide if it's right.

You have no idea if it's right. You have no basis for having an idea. The thing that would have given you a basis is the years of building this stuff by hand, and you didn't do that, because why would you.

So you approve it. It works, after all. And it goes into the codebase, and it's plausible, and it's slightly wrong in a way that won't show up for eight months, and when it does you won't recognize it because you never saw the right version to compare it against.

This is the actual junior developer problem. Not that they can't produce. That they can't evaluate. And the tools have made producing trivially easy while doing nothing for evaluation, which means the ratio of "code that exists" to "people who can judge it" is heading in a direction I don't love.

What we're trying at Corfix

We're a small shop. I'm not running a grad program. What follows is the handful of things we've started doing with our less experienced people, and I want to be clear that "started" is the operative word. Nothing here is proven. Some of it might be wrong.

Explain it before you merge it. If you used a tool to generate something, you walk a senior through it, line by line if needed, and you have to be able to say why each part is there. Not what it does. Why. The first few times this is painful. It's supposed to be. The point isn't to catch bugs. The point is to force the reading that the tool let you skip.

Own something small and real, end to end. Not a ticket. A problem. A specific user has a specific thing that's annoying, and it's yours from "what's actually going on here" through to "did it help." It'll take longer than if a senior did it. That's the cost, and it's a cost worth paying, because it's the only way I know to manufacture the on-ramp on purpose.

Archaeology assignments. Go find out why this bit of the system does the weird thing. Don't fix it. Just come back and tell us why. This is the closest thing I've found to bottling what the legacy code post was talking about, and it works better than I expected, because the tools are actually pretty good at helping you excavate and pretty bad at telling you what matters once you've dug it up.

Customer exposure early, not eventually. If the job is understanding the person holding the phone, there's no reason a junior should have to wait three years for that. Get them on a call. They'll be quiet. That's fine. They'll hear something a senior would have filtered out as obvious.

What I genuinely don't know

Whether any of this replaces the grind. My honest guess is it replaces some of it, and the rest we're going to find out about the hard way in about five years.

How much slower to accept. Every one of the things above is slower than letting the tool do it and moving on. In a quarter where things are tight, that slowness is going to look like waste, and I'm going to have to defend it to people who are reasonably asking why the junior is spending a week on something that could ship in a day. I don't have a clean answer. "Because otherwise we have no seniors in 2035" is true, and it's also not a great thing to say in a sprint review.

Whether we're just recreating the old hazing with better branding. There's a version of "explain every line" that's mentorship and a version that's making juniors miserable for the sake of tradition. I think we're on the right side of it. I'd want to ask them, not me.

Whether the actual answer is that the job changes so much that "junior" stops meaning what it meant. Maybe the on-ramp isn't CRUD anymore. Maybe it's something we haven't named yet, and in ten years someone writes a post about how the kids these days never had to do it.

If you've got juniors on your team

Five things you can start next week. None of them need a program.

1. Make "why is this here" a review question

For anything generated, ask it. Every time. Not "does it work." Why is this line here.

2. Give them a problem, not a ticket

One small, real, annoying thing that a real person has. Theirs, start to finish.

3. Send them digging

Pick a weird corner of the system. Have them come back and explain it. Don't let them fix it.

4. Get them on a customer call

Early. They don't have to talk.

5. Protect the slowness

Someone will ask why this is taking so long. Have an answer ready. The answer is that this is how you make the next senior developer, and there is no faster way that we know of.

The point

For twenty years the industry got its engineering intuition for free, as a byproduct of work that needed doing anyway. The work doesn't need doing anymore. The intuition still does.

That means we have to build it on purpose now, at a cost, in a way that will never show up on a velocity chart, for a payoff that arrives years later in a different budget.

Nobody's going to make you do it. It'll be very easy not to.

That's exactly why it's the job.