How to run code review as your primary teaching channel

The problem: a junior team, an inspection deadline, and no room for a training programme

I spent a good chunk of last year embedded in an engineering team in the UK education sector. Around nine developers, predominantly junior, several of them bootcamp graduates a few months out of their course. The work was inspection-driven, which is to say there was a hard external date and a fixed scope, and the team had to ship.

A parallel training curriculum was not on the table. There was no week to spend on a workshop, no afternoon for a brown bag, no quiet sprint to absorb a new pattern. Whatever the team learned, they had to learn while building the thing they had been hired to build.

So I made code review the primary teaching channel. Not a side effect of code review. The actual channel.

This post is about how I ran that, what shifted in the discipline, and why I think code review is the most underused leadership tool on a junior-heavy team.

Why code review beats a separate training track

The work itself is the most honest teacher. A pattern explained in the abstract bounces off; the same pattern explained against the developer's own code, on the PR they opened ten minutes ago, sticks. They have a concrete piece of code in front of them, a real question about it, and a reviewer who can answer that question with the specific consequences attached.

A pull request is also the single moment in the week where a developer is most receptive. They have just finished something. They want feedback. They are asking. Compare that to a Tuesday afternoon training session where they are politely pretending to be interested in a class hierarchy that has nothing to do with the bug they were fighting that morning.

And it scales the way training does not. A reviewer's time on a PR teaches the author of that PR, but if the reasoning is written down clearly, it also teaches the next person who reads it, and the person searching for prior art on a similar change three months later. A workshop teaches whoever is in the room that day.

So the channel is right there. The question is whether the discipline is set up to use it.

The four shifts

On most teams I have seen, code review runs fast and verdict-shaped. A senior glances at the diff, drops "rename this", "extract a method here", "split this PR", clicks approve, moves on. That works on a team of equals. On a junior team it teaches the developer to ship to please the reviewer, which is almost the opposite of what you want.

Four shifts made the channel actually work.

1. Slow the reviews down

I told the senior reviewers to budget more time for non-trivial PRs and to treat each one as a teaching moment rather than a verdict. If the review felt like it should take fifteen minutes, give it forty.

This is the shift the reviewers pushed back on hardest, and I will come to the cost in a moment. But the principle is straightforward. A fast review only fixes the PR in front of you. A slow review, done well, fixes the next ten.

2. Write the reasoning, not just the verdict

Every non-trivial comment had to explain why, not only what. "Move this to the progress engine" became "Move this to the progress engine because the BFF should not know which source system this field comes from, and here is what breaks if it does."

The verdict only solves one PR. The reasoning solves the category. Once a developer understands that the BFF is meant to be source-system agnostic, they stop putting source-specific logic in it across every feature they touch for the rest of the project. You paid the cost once.

It also takes the personality out of the review. "Do X" reads as authority. "Do X because Y" reads as engineering. Junior developers learn faster from the second, and they push back more usefully when they disagree, because the reasoning is on the table and they can engage with it.

3. Ask questions instead of issuing corrections

This was the one I asked the more experienced reviewers to lean into hardest. Instead of "you need to handle stale data here", try "what would you expect this to do if the e-portfolio feed were a day late?"

The question puts the pattern in the developer's head. They work out the answer. They notice on their own that the code does the wrong thing when the feed is stale, and the correction lands as something they figured out, not something a senior told them. Next time they touch a feed-driven feature, the question is already running in their head before they open the PR.

The correction only fixes that PR. The question rewrites the way the developer reads their own code.

There is a softer benefit too. Questions sit better with someone who is two years out of a bootcamp and feeling the imposter side of things. Corrections accumulate; questions invite. On a junior team that is feeling the pressure of an external deadline, the difference in how reviews feel matters more than people admit.

4. Be specific about what would break

Abstract principles slide off. "This violates separation of concerns" is true and useless. "If we put the source-system check in the BFF, then when the second e-portfolio supplier comes online next quarter we have to change the BFF as well as the progress engine, and the BFF is already the most-touched service in the system" is true and load-bearing.

The pattern I asked reviewers to follow: name the consequence, name the timeline, name the system that would feel the pain. The closer the consequence is to something the developer has already touched, the more the lesson sticks.

A worked example

Imagine a junior PR that adds a date-of-birth field to a learner profile, and pulls it directly from the e-portfolio API in the BFF.

A verdict-only review:

Move this to the progress engine.

A teaching review:

Move this fetch to the progress engine. The BFF should not know which source system supplied a given learner field. Right now it works because the e-portfolio is our only feed, but a second supplier is on the roadmap, and the moment that lands we will be editing the BFF every time a field's source changes. Cleaner if the progress engine resolves the field and the BFF just asks for it. As a check, what would this code do today if the e-portfolio feed were a day late and the field came back null?

Same verdict. Wildly different signal. The first one fixes one PR. The second one teaches the developer the rule (BFF stays source-agnostic), gives them the reason (a second supplier is coming), names the cost (editing the BFF on every field change), and invites them to find a related bug on their own (the stale-feed null case).

The teaching review took maybe four minutes longer to write. It is doing the work of three or four future reviews.

The cost, and why reviewers will object

This is expensive in the moment. A reviewer who is used to clearing ten PRs in an hour will clear three, and they will feel that.

The objection I heard most often was some version of "I do not have time for this". That is a real objection and worth taking seriously. The answer is not to wave it away. The answer is that the time spent on a teaching review is not lost; it is paid forward. If a reviewer writes the reasoning out properly on a PR about source-system coupling, the same reviewer is not writing it out again on the next four PRs that would have made the same mistake.

The payback is in the rate at which the team absorbs patterns and stops needing the same review again. On the engagement I am drawing from, by about month three the senior reviewers were finding less to say on each PR, because the juniors had internalised the architectural shape of the system. That was the win. The investment was the slow reviews in months one and two.

The failure mode

The failure mode is the rushed teaching review, which is to say a verdict dressed up as a comment. "Move this to the progress engine, separation of concerns" is worse than "move this to the progress engine" on its own, because it teaches the developer that the reasoning is a magic incantation rather than something with consequences attached.

I told the seniors: if you are too rushed to write the reasoning out properly, write a verdict and flag the PR for a slower second pass, or skip the review and ask someone else to take it. A verdict-only review on a junior team teaches the developer to ship to please the reviewer. That is the opposite of what you want and it is hard to undo once it sets in.

The other failure mode, less common but worth naming, is the reviewer who uses the question format insincerely. A question that is really a correction in disguise ("do you really think this should live in the BFF?") reads as passive-aggressive, and juniors notice. If you mean "move this", say "move this, because". The question form is for cases where you genuinely want the developer to work the answer out, not for cases where you have already decided.

A short note on tooling

Tooling helps a bit. Saved review templates for the patterns you find yourself explaining over and over save typing. A review tool that surfaces the same comment across multiple PRs (so you can point a developer at the previous time this came up) helps consistency.

But the load-bearing change is human. A team with a beautiful review tool and reviewers who write one-word verdicts will teach nothing. A team with the most basic GitHub review interface and reviewers who write the reasoning out properly will teach a lot. The tool is a multiplier on the discipline, not a substitute for it.

Closing

Code review is a leadership channel as much as a quality channel. On a junior-heavy team, with no room for a parallel training programme, it is the most leverage you have. The shifts are not complicated: slow it down, write the reasoning, ask questions, name the consequence. The hard part is convincing senior reviewers that the time is well spent, and holding the line for the first couple of months while the payback compounds.

If you are running a junior-heavy team under a deadline and the training question is keeping you up at night, I am happy to compare notes. No pitch attached.