Engineering Decisions: Code Reviews That Improve Systems, Not Egos

Introduction:

Code reviews are one of the most universally adopted engineering practices. Almost every engineering team does them. Almost every engineering team has strong opinions about how they should work. And almost every engineering team has experienced reviews that felt more like personal critique than collaborative improvement — where the feedback was technically correct but the interaction left the author defensive and the reviewer feeling superior.

The version of code review that improves systems is not the version that catches every style violation, questions every design decision, and demonstrates the reviewer's superior knowledge of the codebase. It is the version that focuses on what matters for the system's long-term health, communicates feedback in ways that are easy to act on, and treats the review as a shared responsibility for quality rather than a gate that one engineer holds over another.

Getting this right requires clarity about what code review is actually for and discipline about what it is not for.

Code Review Has a Specific Purpose:

Code review serves several legitimate purposes — catching bugs before they reach production, sharing knowledge about how the system works, maintaining consistency in approaches that affect everyone who works in the codebase, and ensuring that changes meet the standards the team has agreed on.

It does not exist to demonstrate the reviewer's expertise, to enforce personal style preferences that have no objective impact on system quality, or to give every engineer an opportunity to redesign every feature before it ships. Teams that conflate these purposes produce review processes that are slow, demoralising, and focused on the wrong things.

Clarity about purpose changes what reviewers look for. A reviewer focused on system quality asks whether this change could introduce a bug, whether it handles failure cases correctly, whether it will be understandable to the next engineer who reads it, and whether it is consistent with the patterns the team uses. A reviewer focused on demonstrating expertise asks whether they would have done it differently.

The Highest Value Feedback Is About Correctness and Failure Handling:

Not all review feedback is equally valuable. Comments about variable naming, formatting preferences, and minor structural choices consume reviewer time and author attention without meaningfully improving system quality. Comments about correctness, failure handling, and edge cases directly reduce the probability of production incidents.

The highest value review feedback identifies cases the author did not handle — what happens when this API call times out, what happens when this input is null, what happens when this operation is retried after a partial failure. These are the cases that cause production incidents, and they are the cases that a second set of eyes is most likely to catch that the author missed.

Reviewers who prioritise correctness and failure handling over style and structure consistently provide more value in less time. They find the things that matter and say less about the things that do not.

Feedback Should Be Specific and Actionable:

Vague feedback creates more work than it eliminates. A comment that says "this seems risky" leaves the author guessing about what risk the reviewer identified and how to address it. A comment that says "this operation is not idempotent — if the caller retries after a timeout, it will create a duplicate record — consider adding an idempotency key" gives the author exactly what they need to make a decision and act on it.

Specific, actionable feedback respects the author's time. It tells them what the problem is, why it matters, and ideally suggests a direction for addressing it. The author can then agree and fix it, disagree and explain why, or ask a clarifying question — all of which move the review forward rather than stalling it in a cycle of vague comments and confused responses.

The discipline of writing specific feedback also forces reviewers to be certain they understand the problem before raising it. Vague feedback is often a signal that the reviewer has a feeling something is wrong but has not thought it through enough to articulate what. Forcing specificity either surfaces a real issue or reveals that the concern was not as significant as it seemed.

Tone Determines Whether Feedback Is Heard:

The same technical observation delivered in different ways produces different responses. "This will cause a race condition under concurrent access" is a neutral statement of fact that invites collaboration. "Did you even think about concurrent access?" is an accusation that triggers defensiveness. The technical content is identical. The outcome of the review is not.

Engineers who receive defensive or hostile feedback stop engaging with the substance of it. They either capitulate to end the interaction or dig in to defend themselves. Neither response produces the outcome code review is supposed to achieve — a better system. The feedback may be technically correct and still make the system worse by poisoning the collaborative relationship between reviewer and author.

Tone in code review is not just a matter of being nice. It is a matter of whether the review achieves its purpose. Feedback delivered with the assumption that the author made a reasonable decision that missed something — rather than the assumption that the author was careless or incompetent — is more likely to be heard, considered, and acted on.

Review Scope Should Be Bounded:

One of the most common failure modes of code review is scope creep — a reviewer who starts reviewing the change being made and ends up redesigning the system it touches. "While I'm here, have you considered refactoring this entire module?" is a question that turns a small change into a large project and a focused review into an open-ended architectural discussion.

Reviewers who consistently expand scope slow down delivery without improving quality proportionally. They also create uncertainty for authors about what a review is actually evaluating — the change being submitted or the author's judgement about what to change.

Scope should be bounded to the change being reviewed. If a reviewer identifies a broader issue that the change reveals but does not cause, the right response is to note it separately — a follow-up ticket, a team discussion, a future refactoring item — not to block the current change on resolving it.

Approving Is a Responsibility, Not a Formality:

In teams where review approval is a required step before merging, approval can become a formality — a click that unblocks delivery rather than a considered judgement that the change is ready. Reviewers who approve changes they have not genuinely reviewed are not providing quality assurance. They are providing the appearance of it while accepting none of the accountability.

Genuine approval means the reviewer understands what the change does, believes it is correct, and is willing to share responsibility for its consequences in production. This standard does not require reviewers to catch every possible issue — that is not realistic. It requires them to engage seriously with the change rather than clicking approve to be helpful.

Teams that treat approval as a genuine responsibility produce reviews that are taken seriously by both authors and reviewers. Teams that treat it as a formality produce a review process that exists on paper but provides no real quality signal.

Conclusion:

Code reviews improve systems when they are focused on what actually matters — correctness, failure handling, and consistency — communicated in ways that are specific, actionable, and respectful, and scoped to the change being reviewed rather than expanded into architectural redesigns.

The engineering teams that get the most value from code review are not the ones with the most rigorous processes or the most thorough reviewers. They are the ones where review is understood as a shared responsibility for system quality, where feedback is delivered with the assumption of good intent, and where the goal is always a better system rather than a demonstration of who knows more.