Forty comments, nothing changed
The pull request is medium-sized: a new retry mechanism around payment webhook processing. It sits in review for three days. It gathers forty-one comments. Import ordering. A variable that could be more descriptive. A preference about early returns. Two threads, nine replies deep, about whether a helper belongs in this file or the next one.
Comment count on the retry semantics themselves: zero. Nobody asks what happens when the webhook arrives twice, because the retry makes that possible now. Nobody asks how the timeout interacts with the queue's own redelivery. The change ships with a subtle double-processing bug and impeccable import ordering.
Every engineer has watched a version of this. It feels thorough. It generates artifacts of diligence, comments, iterations, approvals. And it changes almost nothing about the actual quality of what ships, because all of the attention went where attention is cheap.
“The change ships with a subtle double-processing bug and impeccable import ordering.”
Why the comments cluster on trivia
This is not laziness. It is physics. Spotting a naming inconsistency takes five seconds and no context. Evaluating whether a retry policy is safe requires understanding the queue, the payment provider's delivery guarantees, and the downstream consumers, twenty minutes of context the reviewer may not have and the diff does not show.
So review effort flows downhill to whatever the diff makes visible. The diff shows lines, so lines get reviewed. It does not show the alternative designs not taken, the requirements the author guessed at, the invariant two files away that the change quietly violates. The most consequential properties of a change are exactly the ones a line-by-line reading cannot see.
Add the social layer: a comment about naming is safe, nobody argues, it demonstrates participation. A comment questioning the design risks a real conversation, maybe a confrontation, maybe the discovery that you misunderstood something. Under deadline pressure, the incentives all point one direction, and forty-one comments about imports is where they point.
The result is a ritual that performs quality rather than producing it. Everyone participates in good faith. The ritual still ships the bug.
“Review effort flows downhill to whatever the diff makes visible, and the most consequential properties of a change are the ones a diff cannot show.”
What review is actually for
Here is the reframe that separates the best reviewers I have worked with from everyone else: they do not treat review as bug-hunting. Reviews are demonstrably bad at finding bugs; tests, types, and production find far more. They treat review as the one structured moment where two mental models of the system get compared.
Context transfer, in both directions. The reviewer learns what is changing and why, which is what makes them capable of maintaining this code, debugging it at 2am, and building on it next quarter. The author learns what the reviewer knows that they did not: the incident from last year, the other team consuming this API, the migration that makes this approach a dead end. A review where no knowledge moved in either direction was a formality, whatever its comment count.
Assumption surfacing. Every change is built on guesses: about load, about inputs, about what callers do, about what the requirements meant. The author cannot see their own guesses; that is what makes them guesses. The reviewer's irreplaceable move is asking the question the author did not think to ask themselves. What happens if this arrives twice? Who else reads this table? Why is this synchronous? The best review comments are almost always questions, and the dangerous answers almost always begin with "I assumed."
That is a completely different job from scanning for flaws. It is slower per comment and radically higher value per comment, and it is the job worth designing your review culture around.
“The best review comments are almost always questions, and the dangerous answers almost always begin with "I assumed."”
The habits of reviewers worth having
Watch a genuinely good reviewer work and the habits are consistent.
They read the description and the linked context before the diff, and if the description does not say why the change exists, that is their first comment, because reviewing code without knowing its purpose is proofreading, not reviewing.
They start from the riskiest part, the schema change, the concurrency, the auth check, and spend their budget there, instead of commenting top-to-bottom until fatigue. They say "looks good, one real concern" instead of fifteen equal-weight comments, because they know authors weight all comments equally unless told otherwise, and a wall of nitpicks buries the one that matters.
They state preferences as preferences. "I would use a map here, take it or leave it" costs the author nothing. Preferences dressed as corrections are how review becomes a dominance ritual, and dominance rituals are how teams end up with three-day review latencies, because opening yourself to one becomes something people schedule courage for.
And they approve with questions open when the questions are not blocking. The point was never to withhold approval until the author performs compliance. It was to make sure both people understand what is shipping.
Fixing the system, not the people
Telling reviewers to be better is a wish. The teams that actually escape review theater change the system so the theater has nothing to feed on.
Automate style out of existence, completely. Formatter, linter, import sorter, enforced in CI, non-negotiable and therefore non-discussable. Every style rule that requires a human comment is a design decision you have chosen to relitigate on every pull request forever. The forty-one comments cannot cluster on trivia if the trivia is machine-settled.
Move design review before the code exists. The worst moment to discover the approach is wrong is after it is fully built, which is precisely when pull request review happens. A one-page design note, or even a ten-minute conversation for anything non-trivial, catches at the sketch stage what the PR stage can only catch expensively. Then the PR review can do its real job: verifying the execution of an agreed direction.
Make "how would we know this works" a standard review question, on every meaningful change. Not "did you write tests," which invites checkbox answers, but what observable evidence will exist that this behaves correctly in production. That single question drags review attention from the lines to the behavior, which is where it was supposed to be all along.
And measure review by outcomes, not artifacts. If your review process generates hundreds of comments a week and your escaped-defect rate has not moved, you do not have a quality process. You have a very expensive way of discussing imports. The goal was never more comments. It was fewer surprises.
“Every style rule that requires a human comment is a design decision you have chosen to relitigate on every pull request forever.”