Pair Programming & Collective Code Ownership
本页目录· 6 条
What pair programming is
Two people work on the same problem at the same time, with shared responsibility for the result. It grows out of Extreme Programming and collective code ownership: knowledge and change authority should not be trapped with one person.
Why teams use it
- Real-time review can expose defects and inconsistent standards earlier.
- Continuous dialogue improves shared understanding of requirements and design.
- Knowledge moves across the team, reducing single-person dependency.
- Difficult problems can be explored with two perspectives.
Trade-offs are real: pairing can feel slower, create fatigue, amplify personality clashes or become unequal if one person dominates. Use it selectively where risk, learning or complexity justifies the coordination cost.
Useful modes
- Driver / Navigator: driver types; navigator reviews the larger direction, constraints and next steps. Switch regularly.
- Ping-pong: one person writes a failing test; the other makes it pass; alternate. Strong fit for TDD.
- Tour guide: one person explains architecture and decisions while navigating the code; useful for onboarding and knowledge transfer.
- Backseat driver: an experienced navigator gives more detailed instructions while the learner drives.
- Mobbing: the whole team works on one problem with one active keyboard; useful for difficult or cross-cutting work.
- Unstructured pairing: fluid collaboration without fixed roles; only works when both remain engaged.
A 45-minute FIT5120 pairing protocol
- 5 min — frame: user story, acceptance criteria, risk and intended outcome.
- 15 min — pair: driver narrates decisions; navigator watches the big picture.
- 2 min — switch: change roles and rest attention.
- 15 min — pair: continue, test and question assumptions.
- 8 min — close: run checks, record decisions, update the ticket and name follow-up work.
Habits to protect
- Narrate work at a pace the other person can follow.
- Keep screen access and speaking opportunity equal.
- Navigator asks questions and focuses on design/risk, not every keystroke.
- Pause notifications and take breaks.
- End with feedback on the pairing itself.
- Commit evidence under both contributors’ shared team process; do not let pairing erase individual contribution records.