The Theatre of Pull Requests and Code Review

Original Article ↗ Hacker News Discussion ↗

Small vs Large PRs and Stacked Changes

  • Strong disagreement over “300 LOC / 5–10 minute” PRs and stacked PRs.
  • Pro‑small‑PR side: finer changes are easier to reason about, review faster, build shared context, support trunk-based development and feature flags, and make bisecting / rollback safer.
  • Anti‑small‑PR / stacked side: many small, interdependent PRs hide how changes interact, increase context switching and queue times, and create rebase/branch-management overhead. Some reviewers prefer one coherent feature-level PR over many fragments.
  • Several say tooling (GitHub, Perforce, etc.) is hostile to stacked workflows; others point to tools like jj, Graphite, Sapling, git-branchless, git-p4 as partial fixes.

What Code Review Is For

  • Different teams optimize for different goals:
    • sanity/QA and catching bugs earlier,
    • spreading context and ensuring more than one person understands the change,
    • enforcing security/compliance (SOX, healthcare, finance),
    • or mostly box‑ticking and velocity metrics.
  • Some argue PRs should be optional for trivial changes; others want “an extra pair of eyes” even on one-liners.
  • There’s emphasis that reviewing is itself work and should be scheduled and reported as such, not treated as “free overhead.”

Commit Style, History, and “Storytelling”

  • Big split on “story-telling commits”:
    • Supporters: a clean series of atomic commits makes the change easier to understand, review incrementally, bisect, and debug later. Commit messages are seen as crucial for explaining “why.”
    • Skeptics: reviewers mostly look at the final diff and PR description; intermediate commits are personal checkpoints and often noisy (“fix”, “wip”). Many prefer squash‑and‑merge with a single good PR-level narrative.
  • Some insist every commit (at least on main) must compile and pass tests; others call that overzealous except for mainline.

Process, Communication, and Culture

  • Many complaints about performative “LGTM theatre,” review-as-gatekeeping, and KPIs around number of PRs.
  • Repeated advice:
    • provide clear PR descriptions (goal, approach, risks, tests),
    • do self-review and annotate tricky parts,
    • push draft PRs early and involve reviewers before coding heavy features,
    • reject PRs you don’t understand instead of rubber-stamping.
  • Some prefer pairing/mobbing and design discussions up front; PRs then become a final sanity check rather than the main review venue.

AI and Tooling

  • Several suggest using LLMs for “semantic linting” and shallow pattern/style checks, reserving human attention for design and logic.
  • Others worry heavy AI-generated code plus weak review is a fast path to tech-debt hell.