Code Review Is About the Team, Not the Code

Two Kinds of Review

I’ve been on teams where review was a fight.

“Why didn’t you do it this way?” with no explanation attached. “This is wrong” as an entire review. Forty comments about brace placement and not one about the fact that the whole approach falls over under concurrency. Approval held hostage to somebody’s personal taste, which you were expected to learn by trial and error.

Those teams were miserable, and the code wasn’t even good.

I’ve also been on teams where review was a conversation. Comments that explained the reasoning behind a suggestion. Questions rather than demands. Discussions where the reviewer came away understanding a corner of the system they’d never touched, and the author came away with a better approach than the one they turned up with.

Those teams shipped better work with dramatically less drama. And the difference wasn’t skill. Both sets of people were perfectly capable. The difference was what everyone thought review was for.

What It’s Actually For

Spreading knowledge. Every review teaches the reviewer about code they didn’t write. When Alice reviews Bob’s work, she learns how that part of the system hangs together. Do that consistently for six months and you no longer have a team where exactly one person understands billing.

Validating design. Seeing code in context catches things isolated development misses. “This works, but have you noticed what happens when it runs at the same time as the import job?” You are never getting that from a test suite.

Teaching in both directions. Juniors learn from senior feedback, which is the obvious half. The half people forget is that a junior asking “why do we do it like this?” is often the only thing that makes anyone re-examine a decision made three years ago for reasons that stopped applying two years ago.

Making ownership real. When the team reviews the code, the team owns the code. It’s the practical mechanism that stops “ask Bob, he wrote that” becoming the answer to everything.

Bug Catching Is a Side Effect

It’s a nice side effect. It isn’t the point.

If you’re relying on somebody eyeballing a diff to catch your bugs, something upstream has already failed. Humans reading code are terrible at spotting off-by-one errors and rather good at spotting “this design is going to hurt us in six months.” Tests are excellent at the first and completely useless at the second.

So use each for what it’s actually good at. Push correctness down into the test suite where it’s cheap and repeatable, and spend the expensive human attention on the things only a human can see.

The Argument For Gatekeeping

Quality does matter and I’m not pretending otherwise. Sometimes code genuinely shouldn’t be merged, and somebody has to be willing to say so. A review culture so gentle that nothing is ever blocked isn’t collaborative, it’s decorative.

Efficiency matters too. A deep knowledge-sharing review takes real time, and not every change deserves one. A dependency bump does not need a Socratic dialogue.

Where I Might Be Wrong

My experience skews towards small, fairly senior teams where you can assume good intent and broadly similar standards. On a large team, or one with a wide spread of experience, firmer gatekeeping may genuinely be load-bearing.

And culture is hard to shift. If you’ve inherited an adversarial review culture then “just be nicer” isn’t actionable advice, it’s a wish. The only thing I’ve seen actually work is one person reviewing differently, visibly, for long enough that it starts to look normal.

The best reviews leave both people smarter than they were. Optimise for that.

How to Review Like It’s Teaching

1. Ask rather than instruct. “What made you go this way?” instead of “this is wrong”
2. Always give the reasoning. A suggestion without a why is just an instruction
3. Separate blocking from non-blocking. Approve with comments far more often than you think
4. Say which comments are taste. “Nit, ignore me if you disagree” costs nothing and prevents arguments
5. Review quickly. A PR sitting for three days costs more than any comment in it will save
6. If a thread hits three replies, get on a call. Text is a terrible medium for design disagreements
7. Say when something is good. Reviews containing only criticism train people to dread them

I’ve learned more from good code review than from any course or book, because the knowledge arrives in context, at the moment it’s relevant, about code I already care about.

And yes, I delete “what” comments when I see them, but that’s a different post.

Until next time, happy coding!