Code Review Is the Highest-Leverage Mentoring There Is

I am twelve hours ahead of most of my team. When I wake up, their day is ending; when I push, they are asleep. There is no whiteboard. There is no "hop on a quick call." If I want to teach someone something, I have to leave it in writing where they can read it later, on their own clock, without me in the room. So the place I do most of my teaching is the pull request. As lead maintainer of kwil-db I have reviewed PRs for thirty-plus external contributors I have never met, across twenty-seven releases, and I am more sure of this than almost anything else about engineering management: code review is the highest-leverage mentoring there is.

The case for it is boring, which is usually how you know something is true. A meeting teaches one lesson to the people who happened to be awake for it, and then it evaporates. A review comment teaches a lesson attached to the exact line of code that prompted it, stays in the thread forever, and gets read by everyone who later touches that file or that PR. The lesson is concrete because it has to be. There is real code in front of you, not a hypothetical. Meetings are the fallback, not the medium. The review is the medium.

The trick that makes it work across a timezone gap is also the trick that makes it actually mentor instead of just gatekeep: you have to spell out the reasoning, not just the verdict. "Change this" is a command. The contributor changes it, learns nothing, and pings me the next time anything looks similar, which, given the gap, costs us a full day of round-trip. "Change this, because under concurrent writes the follower can observe these two updates out of order, and here's the failure that produces" is a lesson. The second one is more expensive to write at 2am my time. It is the only version that scales. If I do my job, the contributor never has to ask me about that class of bug again, and the next person who reads the thread doesn't either.

Review the design before the diff

Most of the leverage is gone by the time there is code to review. Someone who has spent two days building the wrong thing is not in a mood to be taught; they are in a mood to defend the two days. So the most valuable review I do is on the design doc, before a single line is written. That is where you can still change the shape of the thing cheaply. It is also where the gap hurts least: a design discussion is naturally async, naturally written, and a day of latency on a design question costs almost nothing compared to a day of latency mid-implementation.

When I review a design, I am not looking for the clever approach. I am looking for the one with the failure modes I can already name. I would rather ship the boring solution with a benchmark than the clever one without. If the doc doesn't say how it behaves when a follower falls behind, or what happens on the second retry, that is the comment, and it is a better teaching comment than anything I could leave on the finished code, because the author still has every option open.

What a good comment looks like

Over twenty-seven releases I have converged on a rough anatomy for a review comment that teaches instead of just correcting. It is not a style guide. It is the difference between a contributor who needs me and one who doesn't.

• It names the concrete failure, not the preference. Not "I'd do this differently." Say "here is the input that breaks this." If I can't describe the failure, the comment is taste, and I should mark it as taste or drop it.
• It separates blocking from optional. A contributor who can't tell which of my five comments will stop the merge will treat all five as equally urgent, and resent me for it. I say which one is the wall and which are suggestions.
• It gives the why, then trusts them with the how. I explain the constraint; I don't usually paste the fix. People learn the rule better when they write the line themselves.
• It ends, when the work is good, by saying so plainly. "This is the right shape" is mentoring too. Reviews that only ever subtract train people to fear the review.

Do this consistently and something compounds that no meeting produces. The standards stop living in my head and start living in the threads. A new contributor reads how the last three PRs were reviewed and absorbs the bar before I ever look at their code. People start leaving each other the comments I used to leave. The review queue gets faster not because I am stricter but because the team has internalized the reasoning, and reasoning is portable in a way that verdicts are not. That is the whole game: I am not trying to catch every bug myself. I am trying to make myself unnecessary for that class of bug.

People will tell you pairing is the real way to mentor, and in a shared timezone it might be. But pairing teaches one person, in real time, and then it is gone. Across a 12-hour gap it is not even available; "pair with me" means one of us is up at an ugly hour. Review is mentoring that survives my being asleep. It teaches asynchronously, it teaches more than one person at once, and it leaves an artifact the team can keep learning from after I have logged off. AI is a tool I ship with, not a personality, and the same is true of review: it is unglamorous, it is mostly writing, and it is the most durable thing I do for the people I work with.

I'd rather be the engineer whose comments you no longer need than the one whose meetings you can't avoid.