How to Review Code Thoughtfully (and Get Better Reviews)

Code reviews can be the highlight of a workday or the worst part of it, depending on how the team approaches them. The difference is mostly habits — both for reviewers and authors.

Reviewers: comment on what matters

Most code review comments are about taste, not bugs. Mark those clearly: prefix with "nit:" so the author knows it is a suggestion, not a blocker. Save your firm pushback for things that are actually wrong, dangerous, or hard to change later.

If you have ten nits and one real concern, raise the real concern first and let the nits be optional.

Reviewers: explain the why

"Use a different approach" without explanation forces the author to guess what you meant. "Consider X here because of Y" gives them what they need to either fix it or push back. The first is annoying. The second is useful.

Authors: small PRs win

A 500-line PR gets a worse review than five 100-line PRs. Reviewers skim large PRs because the cost of careful reading is too high. Smaller PRs get more careful review and merge faster.

Authors: respond to every comment

Even "agreed, fixed" or "not changing because X" — every comment should get a response. Silently ignoring comments tells the reviewer their feedback is not valued, and they will engage less next time.

Both sides: assume good intent

Written communication strips tone. A comment that sounds harsh in text was probably not meant that way. Read in the most charitable interpretation; write so the most charitable interpretation is the right one. This single habit saves more team friction than any process change.