Treated as a gate to get past, code review breeds resentment and rubber-stamping. Treated as what it's actually for — catching real problems early, spreading knowledge, and keeping a shared standard — it's one of the highest-leverage habits in this entire domain.
3 min read
Code review feels adversarial when it's framed as an obstacle between a finished piece of work and merging it — something to survive with minimal changes, from either side. This framing produces exactly the two failure modes that make review feel like a waste of time: reviewers who nitpick style instead of finding real problems, and authors who treat any pushback as a personal critique instead of useful information.
Effective review comments are specific, explain the why, and distinguish severity — not everything found is equally important, and treating a must-fix bug the same as a stylistic preference wastes the author's attention on the wrong thing:
❌ "This is wrong."
✅ "This will throw if `items` is empty — worth an early return, or does
the caller guarantee it's never empty?"
❌ "Don't do it this way."
✅ "Nit: could use `.map()` here instead of the manual loop — not blocking,
just a smaller diff if you want it."
Labeling something explicitly as a "nit" (a minor, non-blocking preference) versus a real concern helps the author correctly prioritize which comments need real changes and which are genuinely optional.
A reviewer skimming only for formatting and naming misses the actual point:
correctness (does this do what it claims), edge cases (what happens with
empty input, a network failure, a concurrent request), and whether the change
fits the system's existing design — these matter far more than whether a
variable should've been named data or payload. Automated tools (linters,
formatters) should handle style entirely, freeing human review time for the
things a machine genuinely can't check.
A comment on code is a comment on the code, not a judgment of the person who wrote it — internalizing this distinction is what makes review sustainable over an entire career instead of something to dread. The useful response to disagreeing with feedback is asking a clarifying question or explaining the reasoning that led to the current approach, not defending the code as though it were a personal attack.
A pull request that sits unreviewed for days doesn't just delay that one change — it blocks the author from starting their next piece of work cleanly, and stale branches accumulate merge conflicts the longer they wait. Reviewing promptly (even a quick "looks good, one small question" within hours rather than days) is a genuine act of respect for a teammate's time, and one of the simplest ways an individual engineer can measurably speed up an entire team.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What are the three actual purposes of code review described in this lesson?
2. Why should style and formatting generally not be the main focus of a human code reviewer's attention?
3. Why does labeling a review comment as a 'nit' matter?
Software Engineering Fundamentals