Nobody Becomes Senior From a Course

I own code review standards on a platform I've worked on for most of a decade, and I've mentored a number of developers from mid-level into genuinely senior work. The thing that surprised me is how little of that was about teaching anyone to code better.

They could already code. That was never the gap.

The actual gap

What separates a mid-level engineer from a senior one, in my experience, is not knowledge — it's a sense of which decisions are expensive.

A capable mid-level developer will solve the problem in front of them, correctly and often elegantly. A senior one will notice that the problem in front of them is the wrong problem, or that solving it this way makes four other things harder next year, or that this is a decision the team will have to live with long after everyone has forgotten why it was made.

That judgement is built almost entirely from consequences. And consequences take years — unless someone who has already paid for them tells you about it at the right moment.

Why review is the right moment

Review is where the code is real but the cost hasn't been paid yet. That's a narrow and valuable window. Nobody absorbs "think about maintainability" in the abstract; everybody absorbs "this works, and here's what will happen to it in eighteen months when someone adds a second tenant."

So I try to make reviews explain rather than instruct. Not change this, but here's the failure mode I'm worried about. The instruction produces a corrected pull request. The explanation produces someone who catches it themselves next time, which is the only outcome worth the time it takes.

What I got wrong for years

I used to review for correctness, thoroughly, and thought I was being helpful. I was being an expensive linter.

Correctness is the cheapest thing to check and the least useful thing to teach — tests and tooling catch most of it. The things that actually break systems are structural, and they look completely fine line by line. You only see them if you're reading for shape rather than for errors.

I also used to over-review: forty comments on one pull request, every one defensible, the overall effect demoralising and unlearnable. Three comments that explain the reasoning beat forty that assert a preference. Nobody has ever internalised forty things at once.

The part that isn't about code

The mentoring that worked best was mostly permission — telling someone that the confusing part of the system is genuinely confusing and not a gap in them, that the question they think is too basic is the question everyone else also has, that the decision they're agonising over is genuinely hard and that's why it hasn't been decided yet.

A lot of people stall out at mid-level not for lack of ability but because they think everyone else finds it obvious. They don't.