To pair or not to pair?
summary
Pairing claims concrete wins: reduces defects by doing just‑in‑time code review, cuts relearning and handoff loss (Poppendieck estimate: ~50% tacit knowledge lost per handoff), lowers team WIP by turning eight streams into four pairs, and enables trunk‑based development with daily merges (Accelerate/State of DevOps correlation). It requires skills—feedback, pacing, breaks, role switching—and can be exhausting; use pair rotation judiciously, treat it as pair development not constant coding, and expect initial friction that pays off in maintainability and collective ownership.
AI-written summary · about
chapters (10)
- 0:00Start
- 6:46How Pair Programming Can Increase a Team's Effectiveness
- 7:14Benefits
- 7:40Extreme Programming Book
- 9:317 Wastes of Software Development
- 10:21Relearning
- 14:42Our Iq Drops More Points When We Multitask than It Does When We Smoke Marijuana
- 17:38Most Common Challenges of Pairing
- 26:34The Fluency Heuristic
- 28:12Conclusion
related talks
18mWhy we pair?
44mWhat We Learned in 8829 Hours of Pair Programming
23mWarm-Up Talk: Perceptions of Pair Programming
01h 01mPairing, Sharing, Caring - One team's journey to Pair Programming
48mHow to Really Work as a Team - From Sleepy to Strong Pair Programming
32mHow to work as a team, sleepy to strong pair programming
32mMaximizing the Fun Pair Programming Benefits
49mPromiscuous Pairing - What Really Makes Pairing Work