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
but,
- 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
but,
- 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