The Art of Code Review

A good code review is not a gate. It is a conversation between the person who wrote the change and the person who will have to live with it next. When reviews go wrong, it is almost always because one side forgot that.

Review the change, not the person

"Why did you do it this way?" lands very differently from "This is wrong." The first invites context - maybe there is a constraint you cannot see from the diff. The second starts a defense. I try to phrase comments as questions when I am genuinely unsure, and as clear suggestions with reasoning when I am not. Tone is not decoration; it is the difference between a teammate who learns and one who ships around you.

Separate the blocking from the nice-to-have

Not every comment deserves to hold up a merge. I prefix non-blocking notes with nit: so the author knows they can take it or leave it. This keeps the actual blockers - correctness, security, data integrity - from drowning in a sea of style preferences that a linter should have caught anyway.

Small PRs get real reviews

A 60-line change gets read line by line. A 2,000-line change gets a quick scroll and a "looks good to me" that helps no one. If you want careful review, make careful review possible. Break the work down, land it incrementally, and accept that the cost of more PRs is far lower than the cost of a rubber-stamped one.

The goal is shared ownership. Done well, review is the cheapest way a team has to spread knowledge and catch the bug that only the second reader ever sees.