Code reviews do find bugs

Original Article ↗ Hacker News Discussion ↗

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.