Code reviews do find bugs
Claims that code reviews “don’t find bugs” are challenged with both data and experience suggesting they do catch defects, improve design, and reduce long‑term tech debt—but often at significant cost in time and process overhead. Commenters debate when reviews should be mandatory versus optional, how to avoid nitpicking and gatekeeping, and whether alternatives like pair programming, strong testing, feature flags, or post‑merge review can deliver similar benefits with less friction. Many conclude that reviews are most effective when supported by automation (tests, linters, formatters) and a healthy team culture, and when tailored to a team’s size, risk profile, and experience level rather than applied as a rigid best practice.
Perceived benefits
- Many commenters say reviews routinely catch bugs and edge cases, sometimes averting outages or data loss.
- Reviews surface tech debt, code smells, and poor interfaces early, improving long‑term maintainability.
- Knowing code will be reviewed makes authors more careful; some claim error rates rise when reviews are relaxed.
- Reviews help share context and keep the team aware of changes, and can be strong mentoring/learning channels, especially for juniors or newcomers.
Costs and failure modes
- Common complaints: time sink (several hours/week), PRs blocked waiting for review, context switching, and large unreviewable PRs.
- In many teams reviews become rubber‑stamps, nitpicking sessions, or “kangaroo courts” driven by power, ego, or politics.
- Follow‑up work (“we’ll fix this later”) and TODOs often never happen; tech‑debt tickets languish at low priority.
When and how to review
- Several advocate small, coherent, reviewable PRs; large ones are seen as anti‑pattern.
- Opinions split on blocking vs post‑merge reviews. Some like post‑commit or “ship/show/ask” models; others insist critical code must be reviewed before merge.
- Some reviewers approve by default and only block for serious issues; minor comments are marked explicitly as non‑blocking.
- There’s disagreement on meetings: some value synchronous walkthroughs for complex PRs, others find any PR meeting intolerable.
Culture, power, and psychology
- Effective review cultures are described as intentional: clear expectations, priority for reviews, positive feedback, and visible support from leadership.
- Issues raised: ego and defensiveness, stacked‑ranking games (deliberately delaying others’ PRs), stratification between seniors and juniors, and review fatigue for a few “workhorse” reviewers.
- Others stress “kind, not nice” feedback, avoiding personal attacks while being candid.
Tooling and automation
- Strong support for offloading style/format to formatters and linters so reviews focus on logic and design.
- Static analysis, tests, CI, and review environments are seen as essential complements; repeated bug patterns in reviews should trigger new automated checks.
Overall
- Broad agreement that reviews can be valuable, but only when scoped sensibly, supported by tooling, and embedded in a healthy team culture.
- Disagreement remains on whether mandatory pre‑merge review for every change is worth its cost.