The Code Review That Nobody Looks Forward To
Code reviews — the practice of having at least one other developer read and comment on code before it’s merged into the main codebase — provide genuine value: they catch bugs before they reach production, they spread knowledge about different parts of the codebase across the team, they enforce consistency standards, and they provide mentoring opportunities for less experienced developers. They also, when done poorly, create interpersonal friction, damage psychological safety, slow down development unnecessarily, and produce the kind of nitpick-heavy review that makes developers dread the process.
The difference between code reviews that add value and code reviews that create friction is largely in how feedback is given rather than in what feedback is given. The same technical concern expressed as ‘this will cause a memory leak in high-load conditions — consider using a connection pool here because [reason]’ versus ‘this is wrong’ produces different outcomes for both the code quality and the working relationship.
The Tone That Makes Feedback Receivable
Code review comments that use ‘I’ or ‘we’ framing rather than ‘you’ framing produce less defensive responses: ‘I find this difficult to follow — could we add a comment here explaining the business rule this implements?’ rather than ‘you made this confusing’ puts the reviewer’s experience and a collaborative solution in the sentence rather than the author’s failure. This isn’t linguistic softening of legitimate feedback — it’s a communication approach that produces better outcomes because feedback that the recipient can hear and act on is more valuable than feedback that’s technically correct but produces defensiveness.
Distinguishing blocking issues (that must be addressed before the code can be merged) from non-blocking suggestions (improvements that would be nice but aren’t required) is a practice that respects both code quality standards and the author’s time. A review with 15 ‘required’ changes when 3 of them are genuinely blocking and 12 are stylistic preferences treats the author’s attention as infinite and the reviewer’s preferences as requirements. Being explicit about which comments are blocking (‘Blocking: this will cause incorrect results in the edge case where X is null’) versus optional (‘Nit: this could be slightly more readable if we…’) helps authors triage their response appropriately.
What to Focus On and What to Automate Away
The most valuable code review attention goes to: logic errors that tests didn’t catch, architectural concerns about how the code fits into the broader system, security vulnerabilities that the author may not have thought about, edge cases that the implementation doesn’t handle, and clarity improvements that would help the next person reading the code. These are the issues where human judgment provides value that automated tools don’t.
The issues that should be handled by automated tools rather than in code reviews: code style (formatters like Prettier and Black handle this automatically), linting violations (linters catch these before the code reaches review), and test coverage thresholds (CI/CD pipelines enforce these). Spending code review time on ‘this line should have a space before the bracket’ is time not spent on ‘this function is doing too many things and will be hard to test’ — a consistently worse trade-off for everyone involved.
Reviewing Code You Disagree With vs. Code That’s Wrong
The distinction between code that’s objectively wrong (it will produce incorrect results, it has a security vulnerability, it doesn’t handle the specified requirements) and code that’s written differently from how the reviewer would write it is important and often missed in code review practice. Code that’s wrong should be changed; code that’s a different stylistic choice from the reviewer’s preference should be commented on with appropriate weight (a ‘consider’ or ‘I’d prefer’ rather than a ‘must change’).
Team codebases are written by multiple people and will reflect multiple preferences. Codebases where every code review is an opportunity for the reviewer to impose their specific preferences produce developer frustration and slow down code velocity without proportional quality improvement. Codebases where reviews focus on correctness, security, and clarity standards produce both quality and velocity — and developers who are willing to participate in code review because the experience is constructive.
Receiving Code Review Feedback: The Other Half
Code reviews are bidirectional: giving feedback well is one skill; receiving feedback well is another that’s equally important for code review culture. The author who responds to every critical comment with a justification of their original approach, who takes stylistic suggestions as personal criticism, or who marks reviews as approved without reading the feedback creates a review culture where reviewers stop engaging substantively.
The author practices that make code review productive: read each comment for its underlying concern rather than its specific suggestion (the reviewer’s suggestion may not be the best solution, but the concern they identified probably deserves a response), respond to each comment explicitly (either implementing the suggestion, explaining why the current approach is correct, or opening a discussion about the trade-offs), and separate the code from personal identity (the feedback is about the code as it exists now, not about the author’s capabilities or worth as a developer). Code that gets better through review is the desired outcome for everyone — keeping that shared goal visible makes the process work.
