Sherlock Holmes and Pairing
summary
Argues pairing beyond coding with concrete practices and outcomes: driver/navigator roles where the navigator asks targeted questions and supports decisions, keyboard swaps every 2–5 minutes, and feedback cycles measured in seconds; recommends pairing with testers, analysts and business to produce cleaner code, shared domain knowledge and faster failure discovery; warns pairing takes longer and fails with no time or poor chemistry; cites examples like code retreats, a 200 wpm typing anecdote and Ron Jeffries asking guiding questions.
AI-written summary · about
chapters (4)
- 0:00Start
- 12:46Being a navigator is hard
- 19:51Fastest feedback cycle in Agile
- 25:49Outcome: be a better listener
related talks
32mI Have Pair Programmed for 27,000 Hours: Ask Me Anything!
18mPolicing and Pairing: An Unlikely Preparation
34mPair Programming: Better Than Adderall
48mPair Programming, TDD and Other Impractical Things
41mPair Programming
52mPair Programming: Poop & Pee adventures
53mHow to really work together as a team
33mCoaching through Coding