Code review is the highest-leverage activity in software development. A single well-placed comment can prevent hours of debugging, propagate a pattern across a codebase, or shape how a junior engineer thinks for years. Most teams treat it as a gate. The best teams treat it as a conversation.
Distinguish Blocking from Non-Blocking
Not all feedback is equal. A security vulnerability blocks the PR. A naming preference is a suggestion. Make the distinction explicit — prefix comments with [blocking], [suggestion], or [nit]. This removes ambiguity and lets the author prioritise. Vague feedback creates friction; clear feedback creates trust.
Ask Questions, Don't Make Demands
The best review comments are questions: 'What happens when this list is empty?' rather than 'Add a null check.' Questions preserve the author's agency, create a learning moment, and often reveal that you were missing context. You might be wrong — questions acknowledge that.
Review the Design, Not the Style
Linters and formatters exist precisely so humans don't have to argue about spaces and semicolons. Use them. Reserve your review energy for correctness, architecture, edge cases, and maintainability. If you're spending more than 10% of review time on style, your tooling is doing too little.