Code Review as a Skill: What Good Feedback Actually Looks Like

Code review is treated as an obvious, self-explanatory skill — read the diff, leave comments. In practice, the difference between a review that genuinely improves a codebase and one that just produces friction and defensiveness comes down to a handful of specific, learnable habits.

Comment on the code, never on the person

"This creates a race condition because two requests can both read the old state before either writes" describes the code and is falsifiable — either it's true or it isn't. "You didn't think this through" describes the person, invites defensiveness instead of a technical response, and adds no information the first version didn't already convey more usefully.

Separate "this is wrong" from "this is a preference"

A genuine bug (a real correctness issue, a security gap, a broken edge case) is worth blocking a merge over. A stylistic preference (a different variable name you'd have chosen, a slightly different function structure) is worth a suggestion, clearly labeled as one — not the same weight as a bug, and not phrased with the same urgency. Conflating the two is the single fastest way to make a reviewer's feedback feel arbitrary rather than trustworthy.

Ask a genuine question before asserting a fix

"Why did you reach for a class here instead of a plain object?" surfaces the author's actual reasoning — sometimes revealing a constraint the reviewer didn't know about, sometimes revealing a genuine gap in the author's thinking either way, it's a real exchange of information, not a one-directional correction the author has to silently accept or push back against.

Explain the why, not just the what

"Use useMemo here" is an instruction to follow. "This recalculates on every render because it's not memoized, and it's an expensive computation given the list size" is the same suggestion, plus the reasoning — and the reasoning is what a developer actually retains and applies to the next, different piece of code they write on their own, long after this specific review is forgotten.

Why this is a real, distinct skill worth developing deliberately

A team's code quality compounds through review far more than through any individual's solo output — every one of these habits is the actual mechanism by which review makes a codebase (and the team writing it) genuinely better over time, rather than just gatekeeping merges. It's a skill worth practicing as deliberately as any technical one covered elsewhere in this blog, not an assumed byproduct of being a good individual engineer.