Why Most Code Reviews Fail
There are two common failure modes:
The rubber stamp: PRs sit for days. When someone finally reviews, it's a quick scroll and an approval. Nothing of consequence is caught. The review exists to satisfy a process requirement, not to improve the code.
The adversarial review: Every PR becomes a negotiation. The reviewer rewrites the author's code in comments. The author defends every line. Both parties leave feeling worse. Junior developers stop pushing PRs.
Both are symptoms of the same root problem: the team hasn't agreed on what a code review is for.
What Code Review Is Actually For
Code review has three legitimate purposes, in rough order of importance:
- Knowledge sharing — every review is an opportunity for the reviewer to learn, and for the author to get a second perspective
- Catching mistakes — logic errors, missing edge cases, security issues
- Maintaining consistency — naming, structure, patterns
It is not for the reviewer to impose their stylistic preferences. If you'd have solved it differently, that's worth mentioning once — "I might have approached this as X, curious why you went with Y" — but it's not grounds for a blocking comment.
Norms That Help
Authors provide context. Before requesting review, the PR description should answer: what does this change, why does it exist, how did you test it, anything you're unsure about?
Reviews have a deadline. Agree on a turnaround time — 24 hours is common. Stale PRs are demoralising and create merge conflicts.
Distinguish blocking from non-blocking comments. Prefix blocking issues with [blocking] and suggestions with [nit] or [suggestion]. This removes ambiguity about whether the author has to act.
Approve with outstanding nits. If the only remaining comments are minor, approve the PR and let the author decide whether to address them. This prevents the endless cycle of "LGTM except for..."
The Senior Engineer's Responsibility
If you're the most senior person reviewing code, your tone sets the culture. Harsh reviews from seniors normalise harshness throughout the team.
The most effective reviewers I've worked with ask questions more than they give directives: "Why is this necessary here?" teaches more than "Remove this."
A Useful Heuristic
Before posting a review comment, ask yourself: would I say this out loud to the author's face in a supportive conversation? If the answer is no, rewrite it.