James Shore

in 99 words

It's more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.

The driver types. She focuses on tactics--writing clean code that compiles and runs. The navigator focuses on strategy--how the code fits into the overall design, which tests will drive the code forward, and which refactorings will improve the entire codebase.

Pairs self-organize by selecting partners who can best help with the current task. They switch every few hours to share perspectives and knowledge.

as haiku

Summer bakes the earth
Heads together, we ponder
Aha! An insight.

Behind the Scenes

Iterative Writing

Poster

Download this poster!

Inside the Book

• Pair Programming
• Why Pair?
• How to Pair
• Driving and Navigating
• Sidebar: Pairing Tips
• Pairing Stations
• Challenges
  • Comfort
  • Mismatched Skills
  • Communication Style
  • Tools and keybindings
• Questions
  • Isn't it wasteful to have two people do the work of one?
  • How can I convince my team or organization to try pair programming?
  • Do we really have to pair program all the time?
  • How can I concentrate with someone talking to me?
  • What if we have an odd number of programmers?
  • There are only two (or three) of us. Should we still pair all the time?
  • We get engrossed in our work and forget to switch pairs. How can we encourage more frequent pair switching?
  • How can we pair remotely?
• Results
• Contraindications
• Alternatives
• Further Reading