Pairing vs. Code Review: Comparing Developer Cultures

Prerequisites for success

There are a few nonnegotiables that are common across both of these paradigms.

  • Solid continuous integration
  • Talented core developers
  • Agreement on the importance of code quality
  • Iterative self-organization

The joys of pairing

  • Everybody gets better together
  • Pairing can balance the natural daily ebbs and flows of energy
  • A peer generates motivation for self-improvement
  • Tactical decisions are made more easily and with better results
  • [Stronger] concept of collective code ownership


  • Pairing is sensitive to team balance
  • Pairing culture can breed monoculture
  • Pairing does not lend itself to hammock problems [decisions that require more deep thought or creativity]
  • Sometimes you end up needing code review anyways

The joys of code review

  • Nobody sees your code until you’re ready [but] motivating pressure to perform well is still there
  • No barriers to taking on deep thought problems [allowing] for a larger toolbox of problem solving techniques
  • You are defined by your code [which] lends itself to a wider pool of personality types
  • Code reviews are asynchronous
  • Forces you to think about your values more-so than pairing does


  • Code reviews don’t keep you company
  • Privacy vs self-control: It’s all up to you
  • Code reviews can stack up
  • “Eh, seems fine to me”: (…) likely to be more lenient on code quality