Code review antipatterns

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Many commenters find the antipatterns highly relatable and say they’ve seen most or all of them in real teams.
  • Some note that good review cultures are rare; they’ve mostly seen either rubber-stamping or “death by a thousand cuts.”
  • A few joke about training LLMs either to follow the antipatterns or to detect and correct them.

What code reviews are (and aren’t) for

  • Several argue reviews should focus on design sanity, complexity, readability, and test coverage, not bug-hunting or manual QA.
  • Others admit they rely on running the code or tests because “reading code is hard,” especially for high‑risk areas.
  • Reviews are also framed as knowledge transfer, shared ownership, and backdoor prevention, not just defect finding.

Antipatterns in practice

  • Repeated complaints about:
    • Nitpicking style, spelling, and trivial renames.
    • “Ransom note” behavior: blocking a focused PR on unrelated refactors or documentation overhauls.
    • Priority inversion: long lists of nits followed by a late “bombshell” design objection.
    • Silent or slow reviewers who intermittently respond just enough to keep PRs blocked.
    • Political or status games: using reviews to delay rivals or assert control.

Size, rigor, and context

  • Disagreement over acceptable PR/commit size: some aim for 100–200 line changes; others have unavoidable multi‑thousand‑file refactors.
  • Some suggest multi‑day, multi‑pass reviews for critical or embedded systems where updates are costly; others find that level of rigor excessive for typical software.
  • Lack of design context, goals, and background is cited as a root cause of many conflicts and misunderstandings.

Tooling, nits, and automation

  • Strong support for auto-formatters, linters, spell-checkers, and pre-commit hooks to eliminate style/format bikeshedding.
  • Some teams consciously ignore minor style issues in reviews; others insist small problems are still worth fixing but should be automated where possible.

Culture, communication, and remedies

  • Many point to culture and trust as the core issue, not individual pickiness.
  • Suggested mitigations:
    • Distinguish blocking vs “nice-to-have” comments (e.g., conventional comment tags, “[nit]”, “[suggestion]”).
    • Allow reviewers to directly push trivial fixes.
    • Escalation or multiple reviewers when there’s disagreement.
    • Prefer questions and stated concerns over vague or loaded prompts.
    • Use synchronous discussions (chat/meeting/pairing) when async ping‑pong drags on.