Rule 18 of 33 · Chapter IV — How We Build and Review
Review the code, not the coder
Why this rule exists
Code review is one of the most sensitive interactions we have, because you're critiquing something a colleague made, often something they're a little proud of, and the words you choose determine whether review feels like collaboration or judgment. The target is always the code and never the person: 'this function is hard to follow' invites improvement, while 'you always overcomplicate things' invites defensiveness and resentment. When review consistently attacks the work and not the worker, people stop taking feedback personally and start welcoming it, which is the entire goal, because good review makes both the code and the author better. Get the tone wrong and people start writing smaller, safer, less ambitious code just to avoid the sting of review, or worse, they stop asking for real review at all. The trust that lets someone hand you their unfinished work and genuinely want your critique is fragile and worth guarding. How we review is, in the long run, more important than what we catch.
In practice
Comment on the code, using neutral, specific language, and reserve judgment about the person entirely. Ask questions where you're unsure rather than issuing verdicts, since 'what happens if this is null?' is kinder and often more accurate than 'this is broken.' Distinguish clearly between blocking concerns and mere preferences, and don't hold up a merge over taste, prefix the optional stuff so it reads as optional. Praise genuinely good work in the review, because review shouldn't be only a list of problems. Explain the why behind a suggestion so it teaches rather than just corrects. And when you're the author, receive it as a gift aimed at the work, push back with reasoning when you disagree, and thank people, because they spent their time making your thing better.
When it doesn't apply
Patterns that recur across many reviews are a coaching conversation, not a review comment; if someone keeps making the same mistake, talk to them directly and kindly instead of relitigating it in every PR. And serious issues, security holes, data-loss risks, are blocking no matter how gently you phrase them.