The Sequence Of A Code Review Is Part Of The Message

The fastest way to get a blocking issue fixed is not to lead with it. Open a review with the objection and the person on the other end reads the rest of your comment while composing a defence, not while thinking about the fix. Open with two or three specific, true things you noticed they did well, then name the blocking issue clearly and separately from anything else you noticed, and the same person reads the blocking issue as information rather than as an attack. The content of the review does not change. The order it arrives in changes whether it gets heard.

I reviewed a piece of work recently that was genuinely good in several ways worth naming precisely: the risky part of it was cleanly isolated behind a check so it could never run somewhere it shouldn't, the failure handling covered cases that were easy to miss, and there was a test that had clearly been built to prove a specific, sensitive claim rather than just to pad a coverage number. Buried in an otherwise solid piece of work was one thing that had to change before it could be merged, and one thing that would be nice to tidy up but didn't need to hold up the release. I said the good things first, specifically, because they were true. Then I said the blocking issue, on its own line, labelled as blocking. Then the minor note, labelled as not blocking. The response came back within the hour, calm and constructive, with the fix already made.

That is not a story about being nice. Politeness is not what makes this work, and a review built on vague, generic praise fails just as badly as one that opens with the objection — maybe worse, because the recipient can tell the praise is padding and starts discounting everything else you say along with it. What makes the sequence work is specificity and separation. The strengths have to be real and precise enough that the person recognises the thing you're describing as something they actually did on purpose, not a courtesy paragraph inserted because someone once said you should start with something positive. And the issues have to be sorted, explicitly, into what stops the merge and what doesn't, rather than left as an undifferentiated list the recipient has to triage themselves while also managing how criticised they feel.

I think the reason this matters more than it looks is that a code review is one of the few moments in software delivery where feedback is both frequent and personal. It happens on every change, it is attached to a named individual, and it is usually the only place where someone else looks closely enough at your work to have an informed opinion about it. That combination makes reviews a disproportionately large source of how safe people feel bringing imperfect work to a team. A reviewer who consistently opens with the objection is not just being blunt about this particular pull request — they are teaching everyone who reads their reviews that submitting work means bracing for the first sentence. Over enough repetitions, that lesson changes what people are willing to submit before it's finished, which is exactly the kind of early, honest, in-progress work a team most needs to see.

There's a commercial cost hiding in this too, separate from how anyone feels about it. A review that reads as an attack tends to produce a defensive response: justification, pushback, a slower round trip, sometimes a second reviewer pulled in to arbitrate a disagreement that was really about tone rather than substance. A review that reads as informative tends to produce exactly one thing — a fix — and nothing else. Multiply that difference by the number of reviews a team does in a week and the badly sequenced version is measurably slower, not just less pleasant. Engineering leadership spends a lot of energy on process changes to speed up review turnaround — smaller diffs, clearer ownership, stricter SLAs on response time — while the order in which a reviewer writes three sentences is free, available immediately, and often has more effect than any of them.

None of this means softening a real problem or hedging a clear blocking issue into ambiguity. The blocking issue in that review was stated as a blocking issue, without qualification, because pretending otherwise would have been its own kind of dishonesty — the sort that erodes trust just as fast as an unnecessarily harsh opening does, just more slowly and less visibly. The skill is not choosing between honesty and kindness. It's recognising that both the praise and the objection have to be precise, and that precision plus sequence is what turns a list of observations into something a person can actually act on without first working out how upset they should be.

This generalises past code. Any feedback that mixes what's working with what has to change — a performance review, an edit on a document, a note on a proposal — carries the same risk. Open with the failure and the reader spends the rest of the message managing how they feel about the opening line. Open with what's true and specific about what already works, then say clearly what has to change and what's merely optional, and the reader spends the rest of the message doing the thing you actually wanted: fixing it.