Chapter 1: Why Code Review Exists: Quality, Mentorship, Knowledge Sharing, Shared Ownership

Why this matters

Code review is frequently experienced as a gate to get past rather than understood as a practice with several distinct, genuine purposes — and this misunderstanding is the root cause of most review friction. A reviewer who thinks review exists only to catch bugs will focus narrowly on correctness and miss mentorship opportunities; an author who thinks review exists only to slow them down will treat every comment as an obstacle rather than information. Understanding the full set of reasons review exists is what makes it possible to do it well, on both sides.

The four distinct purposes of code review

[BEGINNER]

1. Quality — catching bugs, design issues, and maintainability problems before they reach production, which is the most commonly cited purpose but far from the only one.
2. Mentorship — a genuine, two-way transfer of knowledge: a senior engineer's review comment teaches a junior engineer a pattern or pitfall; a junior engineer's fresh-eyes question ("why is it done this way?") can reveal an assumption a senior engineer had stopped questioning.
3. Knowledge sharing — every review is a forced touchpoint where at least one other engineer becomes aware of a change to the codebase, reducing the risk that any single area is understood by only one person.
4. Shared ownership and reduced bus factor — code that's been reviewed by someone other than its author is, by definition, understood by more than one person — directly reducing the risk that a single engineer's absence, departure, or unavailability makes a critical piece of the system unmaintainable.

[SENIOR INSIGHT] These four purposes can genuinely conflict in a single review, and recognizing which one matters most for a specific PR is real judgment: a one-line hotfix for a live production incident needs its quality purpose served quickly, and deprioritizing the mentorship/teaching purpose (a long comment explaining a better pattern) is the right call in that moment — save it for a follow-up conversation, not the review blocking an urgent fix. A junior engineer's routine feature PR, by contrast, is exactly where investing extra time in the mentorship purpose pays the most compounding dividends, even if it means the review takes longer than the code's inherent complexity alone would justify.

Why "just catch bugs" undersells code review's actual value

[IN PRACTICE] Teams that treat code review purely as a bug-catching gate tend to underinvest in it once they have decent automated test coverage — reasoning "our tests catch bugs, so review is redundant." This misses that automated tests and code review catch fundamentally different categories of problems: tests verify that code does what it was written to do; review is one of the only mechanisms that catches "this code does what it was written to do, but that's the wrong thing to do" (a design misunderstanding, a missed requirement, an approach that will cause problems as the codebase grows) — a category of issue no test, however thorough, can catch, since the test itself was written against the same possibly-flawed understanding as the code.

The shared-ownership payoff, made concrete

[SENIOR INSIGHT] "Reducing bus factor" sounds abstract until it's needed — the concrete value shows up specifically during an incident, a departure, or an unplanned absence. A codebase where every module has been reviewed by at least two or three engineers over its life means an on-call engineer facing an unfamiliar-looking incident in that module has a realistic chance of finding someone with contextual understanding, even if the original author is unavailable. A codebase where review is treated as a rubber-stamp formality (Chapter 11 covers this anti-pattern directly) provides none of this real protection, despite technically having "been reviewed."

Common mistakes

1. Treating code review as existing solely to catch bugs, missing its mentorship, knowledge-sharing, and shared-ownership value — this framing leads teams to deprioritize review once test coverage improves, missing that review catches a different category of problem entirely.
2. Applying the same review depth/priority to every PR regardless of context, rather than recognizing that an urgent hotfix and a junior engineer's routine feature PR call for different balances among review's four purposes.
3. Treating a rubber-stamped, superficial review as equivalent to a genuine one for bus-factor purposes — the actual protective value of shared ownership requires genuine engagement with the code, not just a checkmark in a tool.
4. Assuming good automated test coverage makes code review redundant — tests and review catch genuinely different categories of problems, and strong test coverage doesn't substitute for the design-level and shared-understanding value review provides.

Checklist: keeping code review's full purpose in view

1. Before reviewing, briefly consider which of the four purposes matters most for this specific PR (an urgent fix vs. a junior engineer's learning opportunity vs. a change to a bus-factor-risky module) and calibrate your depth and focus accordingly.
2. Don't treat strong test coverage as a reason to review less carefully — review and testing catch different categories of problems, and both remain valuable regardless of the other's strength.
3. Recognize that a superficial, rubber-stamp review provides none of code review's real shared-ownership protection, even though it satisfies a process requirement — genuine engagement is what actually reduces bus factor.
4. When reviewing a junior engineer's PR, deliberately weight toward the mentorship purpose, even if it means the review takes longer than the code's complexity alone would suggest.

Discussion / interview questions

1. "Why does code review matter, beyond catching bugs?" Strong answer: Names all four purposes — quality, mentorship, knowledge sharing, and reduced bus factor/shared ownership — and explains that automated tests and review catch fundamentally different categories of problems, so strong tests don't make review redundant.

2. "If your team already has strong automated test coverage, is code review still necessary?" Strong answer: Yes — tests verify code does what it was written to do; review catches cases where the code does what it was written to do, but that's the wrong thing, plus provides mentorship, knowledge-sharing, and bus-factor benefits tests can't provide at all.

3. "How would you calibrate your review approach differently for an urgent production hotfix versus a junior engineer's routine feature PR?" Strong answer: For an urgent hotfix, prioritize the quality purpose and move quickly, deferring mentorship-style feedback to a follow-up conversation; for a routine PR from a junior engineer, deliberately invest more time in the mentorship purpose, even if it extends the review beyond what the code's inherent complexity alone would require.

4. "What does 'reducing bus factor' actually mean in practice, and when does its value become visible?" Strong answer: Code reviewed by more than one engineer is understood by more than one person; the value becomes concretely visible during an incident, departure, or unplanned absence, when someone other than the original author needs to understand and modify that code — a superficial, rubber-stamped review provides none of this real protection despite formally satisfying the process.

Chapter summary / cheat sheet

• Code review serves four distinct purposes: quality, mentorship, knowledge sharing, and reduced bus factor/shared ownership — recognizing which matters most for a given PR is real, valuable judgment.
• Automated tests and code review catch fundamentally different categories of problems — strong test coverage doesn't make review redundant.
• The shared-ownership/bus-factor benefit only materializes with genuine engagement — a rubber-stamped review provides none of this real protection.
• Calibrate review depth and focus to context: urgent fixes prioritize quality and speed; routine PRs (especially from less experienced engineers) are where mentorship investment pays the most.

---