Most teams treat code review as a checkpoint: does this pass the bar to merge? That's fine, but it misses the bigger opportunity.
A code review is a conversation about how we build software here. Every comment is a chance to share context, explain a tradeoff, or invite a better idea.
The three kinds of comments I try to write
- "Here's why" — context the author probably doesn't have.
- "Have you considered" — an alternative, not a demand.
- "Ship it" — explicit approval, so the author isn't guessing.
What I try not to do
- Nitpick style that a linter should catch.
- Rewrite the PR in the review — if it's that off, pair on it.
- Leave silence. Silence is the worst review of all.
The goal is a team that gets a little sharper every week.