Why we pair?
summary
Pair development at a legacy bank runs 95% of the time and pairs engineers on mirrored workstations to build microservices and fix message-queue production incidents on Pivotal Cloud Foundry and Spring. Claims: upfront code review replaces many pull requests, teams deliver features faster with fewer defects and more knowledge sharing, and management sees earlier ROI. Requires management buy-in, vulnerability, role swaps to avoid fatigue — recommended swap pairs every 2–3 days and use a pairing matrix and ping‑pong TDD.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:08Defining peer development
- 2:20Benefits of peer programming
- 3:54Team impact and culture
- 7:30Navigating challenges
- 8:52Practical management tips
- 10:31Pairing best practices
- 12:22Mentorship and coaching
- 13:53Tracking team pairings
- 15:27Conclusion and ROI
related talks
30mTo pair or not to pair?
45mPairing As Leadership Function To Drive Performance And Quality
32mMaximizing the Fun Pair Programming Benefits
01h 01mPairing, Sharing, Caring - One team's journey to Pair Programming
44mWhat We Learned in 8829 Hours of Pair Programming
23mWarm-Up Talk: Perceptions of Pair Programming
28mPair Programming as a Mechanism for Growth
32mHow to work as a team, sleepy to strong pair programming