Chapter 11: Anti-Patterns: Rubber-Stamping, Bikeshedding, Gatekeeping, Reviewer Fatigue

Why this matters

Every practice covered so far in this book can degrade into a corresponding anti-pattern under real-world pressure — deadline stress, personality conflicts, or simple fatigue. Naming these anti-patterns precisely is what makes them recognizable and correctable, both in your own behavior and when observed in a team's broader review culture.

Rubber-stamping: approval without genuine engagement

[BEGINNER] Rubber-stamping is approving a PR without actually reading and reasoning about it — a symptom recognizable by its speed (a 500-line PR approved within a minute of being opened) and its content (approvals with no comments at all, on a codebase that surely has something worth a question or suggestion occasionally). Chapter 1 already established that rubber-stamped review provides none of code review's genuine shared-ownership/bus-factor protection, despite formally satisfying a "reviewed" checkbox.

Signal of rubber-stamping: "LGTM" (looks good to me) as the entire review,
submitted 90 seconds after a 400-line PR was opened, with zero comments,
on a repository where this same reviewer approves every PR just as quickly.

Root causes worth diagnosing, since the fix differs by cause: review fatigue (too many PRs to genuinely engage with each one — see below), a cultural norm that treats "blocking someone" as socially costly, or a mismatched incentive structure that rewards fast approvals and doesn't visibly reward careful ones.

Bikeshedding: disproportionate focus on trivial, easily-debated issues

[BEGINNER] Bikeshedding (from Parkinson's classic observation that a committee will spend more time debating the color of a bike shed than approving a nuclear reactor's design, because the bike shed is something everyone feels qualified to have an opinion about) is a review spending disproportionate time and comment volume on trivial, easily-visualized issues (variable naming, formatting minutiae) while a genuinely more significant issue (a design flaw, a security concern) goes unmentioned or under-discussed.

Bikeshedding: 8 back-and-forth comments debating whether a variable should
be named `userList` or `users`, on a PR that ALSO introduces an unvalidated
SQL query nobody commented on at all.

[SENIOR INSIGHT] Bikeshedding is a natural, predictable consequence of the fact that trivial issues are easy to have a confident opinion about and cheap to argue over, while significant issues (architectural trade-offs, security implications) require more expertise and effort to even recognize, let alone debate — this isn't a character flaw in any individual reviewer, it's a systematic bias worth actively counteracting. The direct countermeasure is largely already covered in this book: automate what's mechanically checkable (companion Coding Standards book, Chapter 11, and this book's Chapter 9) so naming/formatting debates don't consume human review bandwidth at all, and use a checklist (Chapter 5) that explicitly prompts for the higher-stakes dimensions (security, design fit) so they can't be silently skipped in favor of the easier, more visible trivial issues.

Review as gatekeeping: blocking for reasons unrelated to actual quality

[SENIOR INSIGHT] Gatekeeping is using review authority to block a PR for reasons that aren't really about the code's actual quality — insisting on a personal stylistic preference as if it were a hard requirement, blocking based on not liking an approach without articulating a substantive technical reason, or (in its most damaging form) using review as a venue to assert seniority or control rather than to genuinely improve the code. This is corrosive specifically because it's often hard to distinguish from legitimate, substantive review from the outside — the author has no easy way to challenge "I don't think this is the right approach" when it's not backed by an articulated, specific technical reason, since there's no concrete claim to engage with or refute.

The countermeasure: every blocking comment should be able to answer "what specifically goes wrong if this merges as-is?" If a reviewer can't answer that question concretely, the comment likely isn't a legitimate blocking issue — at most, it's a matter of taste (Chapter 8), which should be labeled as a non-blocking nit rather than used to hold up the PR.

Reviewer fatigue: the resource constraint underlying several other anti-patterns

[IN PRACTICE] Reviewer fatigue — too many PRs assigned to too few reviewers, or PRs that are individually too large (companion Coding Standards book, Chapter 8) — is frequently the root cause behind rubber-stamping specifically: a reviewer facing an unsustainable review queue rationally (if not consciously) shifts toward faster, shallower reviews just to keep up, even when they know better. This is a systemic, team-level problem, not an individual character failing, and needs a systemic fix:

## Addressing reviewer fatigue systemically
- Distribute review load more evenly (CODEOWNERS/rotation, Chapter 9) rather
  than concentrating it on a small number of senior engineers by default/habit.
- Reduce average PR size (companion Coding Standards book, Chapter 8) --
  smaller PRs are individually faster and less draining to review well.
- Make review time genuinely counted as real work in workload planning,
  not an invisible tax squeezed in around "real" (feature-writing) work.

Common mistakes

1. Approving PRs quickly and without comments as a matter of habit, without noticing this pattern in your own behavior as rubber-stamping rather than genuine, if efficient, review.
2. Spending disproportionate review time on trivial, easily-debated issues (naming, formatting) while a more significant issue goes unmentioned — recognize this as a systematic bias to actively counteract, not just bad luck.
3. Blocking a PR based on an unarticulated "I don't like this approach" rather than a specific, concrete technical concern — if you can't answer "what specifically goes wrong," it's likely not a legitimate blocking issue.
4. Treating reviewer fatigue as an individual reviewer's problem to personally push through, rather than recognizing it as a systemic issue (review load distribution, PR size) requiring a team-level fix.

Checklist: recognizing and countering review anti-patterns

1. Notice your own review speed and comment frequency — a pattern of very fast, comment-free approvals on non-trivial PRs is a personal rubber-stamping signal worth examining.
2. Before raising a stylistic comment, check whether it's already automated (Chapter 9) — if not, consider proposing it as a team convention rather than relitigating it PR by PR.
3. For every blocking comment, be able to answer "what specifically goes wrong if this merges as-is?" — if you can't, reconsider whether it's actually a blocking issue or a non-blocking preference.
4. Address reviewer fatigue systemically (load distribution, PR size, workload planning) rather than treating it as something individual reviewers should just personally manage better.

Discussion / interview questions

1. "What is rubber-stamping, and why is it a real problem even though the PR technically gets 'reviewed'?" Strong answer: Approving without genuine engagement — recognizable by speed and lack of substantive comments; it provides none of code review's real shared-ownership/bus-factor protection despite formally satisfying a "reviewed" checkbox, since no one other than the original author actually understands the change.

2. "What is bikeshedding, and why does it happen even among well-intentioned reviewers?" Strong answer: Disproportionate focus on trivial, easily-debated issues (naming, formatting) at the expense of more significant ones (design, security) — happens because trivial issues are easy to have confident opinions about and cheap to argue over, while significant issues require more expertise to even recognize, a systematic bias rather than a character flaw.

3. "How would you distinguish a legitimate blocking review comment from gatekeeping?" Strong answer: A legitimate blocking comment can answer "what specifically goes wrong if this merges as-is?" with a concrete technical claim; gatekeeping typically can't produce this answer, relying instead on unarticulated preference or authority — if the concern can't be stated concretely, it's likely a matter of taste that should be a non-blocking nit, not a block.

4. "What's the systemic fix for reviewer fatigue, as opposed to an individual one?" Strong answer: Distribute review load more evenly (rotation, CODEOWNERS), reduce average PR size, and count review time as genuine, planned-for work rather than an invisible tax — since fatigue is a team-level resource constraint, not an individual discipline problem to personally push through.

Chapter summary / cheat sheet

• Rubber-stamping: fast, comment-free approval without genuine engagement — provides none of review's real protective value despite formally happening.
• Bikeshedding: disproportionate focus on trivial, easy-to-debate issues over significant ones — a systematic bias, countered by automating trivial checks and using checklists that prompt for higher-stakes dimensions.
• Gatekeeping: blocking without an articulable, concrete technical reason — the test is "can you state what specifically goes wrong if this merges as-is?"
• Reviewer fatigue: a systemic resource constraint (too many/too-large PRs, too few reviewers) that often drives rubber-stamping — needs a team-level fix (load distribution, smaller PRs, workload planning), not individual willpower.

---