PR process killing morale and productivity

Original Article ↗ Hacker News Discussion ↗

Pull request workflows are intended to improve code quality, but many engineers report that excessive bikeshedding, huge comment counts, and adversarial review cultures are instead killing morale and slowing delivery. Commenters argue that most of the pain comes from people and culture—style nitpicks, status games, and unclear expectations—rather than from PRs themselves, and advocate smaller, focused changes, strong automated tooling (linters/formatters/tests), and clearer guidelines on what reviews should block. Some go further, suggesting non‑blocking or greatly simplified reviews in favor of investing more effort in automated testing and developer experience.

Scope of the Problem: PRs vs. Culture

  • Many argue PRs themselves aren’t the issue; it’s adversarial, nitpicky review culture.
  • Examples of extreme bikeshedding: hundreds of comments on a newcomer’s first PR, often over style.
  • Several people link this to broader company culture and management tolerance of toxic behavior, not to PR mechanics alone.
  • Some note reviewers using comments to signal “activity” for performance metrics, regardless of value.

Style, Linters, and Bikeshedding

  • Strong consensus: stylistic disputes should be automated away with linters/formatters and shared style guides.
  • Suggestions:
    • Enforce style in CI or pre-commit hooks; if it’s important enough to comment on, it’s important enough to automate.
    • Use explicit severity labels in comments (“nit”, “consider”, “must fix”) or conventions/emoji to reduce ambiguity.
  • Disagreements:
    • Some see heavy linting (e.g., aggressive formatters) as harmful or cargo cult, forcing unreadable code.
    • Others argue anything a linter can’t enforce is usually not worth fighting over.

PR Size, Process Design, and Flow

  • Frequent claim: enormous PRs (thousands of LOC, 300-comment threads) are inherently problematic.
  • Recommendations:
    • Prefer many small, focused PRs; possibly stacked branches and tooling to support this.
    • Use non‑blocking / “merge first, fix nits later” approaches for trivial issues.
    • Set soft/hard limits on PR size, with exceptions for mechanical refactors.
  • Some teams successfully skip PRs for trusted small teams, reviewing only near release with strong CI.

Reviews vs. Tests and Tooling

  • One strong minority view: code reviews have poor ROI; invest the time in automated tests (especially end‑to‑end) instead.
  • Counterpoint: reviews still catch design issues, unreadable code, and algorithmic mistakes that tests alone may miss.
  • Many emphasize DevX: good CI, auto-formatting, test coverage, and modern tooling as key to both productivity and morale.

Human Factors: Onboarding, Communication, and Power

  • Large comment counts on junior PRs are seen as onboarding and leadership failures.
  • Several advocate:
    • 1:1 or small-group synchronous reviews for big/controversial changes.
    • Setting and documenting review guidelines and expectations up front.
    • Avoiding bullying and “my way or redo everything” behavior; management inaction here is called out as destructive.
  • Time zone gaps and slow, blocking reviews are reported as major morale killers.