Pair Programming

Pair programming =

Two people +

One problem

(and usually, one computer, one keyboard, one screen...

...notwithstanding remote pairing tools and face-to-face pairing desks)

Pairing is like Rally Racing

One driver, one navigator

Listen to how engaged the navigator is. They are focused on what's coming next, but they are not idly speculating. E.g. circa 4min in

Pair Programming Benefits

Two heads are better than one!

  • avoid dead ends and ratholes
  • simultaneously focus on current problem and context (one focus per person)
  • "rubber duck" - explaining a problem out loud often leads directly to a solution
  • instant code review
  • exploit complementary expertise / memory / personality / energy levels
  • less likely to fall into bad habits or get stuck

Pair Programming finds the Maximum of Two Minds

[show graph of maxima]

Every person thinks a little differently, has different expertise / experience / energy / perspective.

So for any given problem, at any given moment, one of the partners will be more able to solve that problem.

With pair programming, you get the best of two at every moment.

(And often you get solutions that are better than any individual would have come up with alone.)

Pairing is efficient

MYTH: pairing reduces productivity by 50%

FACT: pairing (when done well) increases productivity, especially when the problem requires creativity to solve

(pairing also increases communication, satisfaction, and the rate of high-fives per minute)

Pairing is teaching

Docendo discimus - "by teaching we learn"

  • Expert-expert pairing -- best case; experts share tidbits and experience as peers
  • Novice-novice pairing -- good case; novices can struggle and discover together
  • Expert-novice pairing -- beware -- in this case, the expert must accept the role of mentor or teacher, and be patient and let the novice drive most of the time


  • Driver
  • Navigator


  • writes code, runs tests, has control of code
  • focuses on one problem at a time
  • self-narrates at a high level
    • e.g. "Okay, now let's introduce a random number function"
    • NOT "I'm now creating a variable named X that I'm assigning the value 4"
    • assume your navigator can read the code and understand it; the goal is to communicate purpose and intention, not mechanics

Tag Team

Switch roles often!

  • at least once per hour, preferably more frequently
  • pomodoro technique can help -- code for 25 min, then take a 5 min break, then switch drivers

Ping Pong

  • Alice and Bob are pairing
  1. Alice writes a unit test and gets it to fail correctly
  2. Alice hands the keyboard to Bob
  3. Bob writes code until the unit test passes ("goes green")
  4. Bob writes a unit test and gets it to fail correctly
  5. Bob hands the keyboard to Alice
  6. Alice writes code until the unit test passes ("goes green")
  7. Repeat until done!

Breath Mints

It's better to have them and not need them, than to need them and not have them.



  • Talk. A lot.
  • Ask questions.
  • Listen.
  • Say something if you don't understand or disagree.
  • Be patient.
  • Swap roles often.
    • at least every 30 minutes
  • Take breaks regularly.
    • at least once an hour
  • High five!
  • Enjoy it!


  • get too frustrated
  • be a keyboard hog
  • be a backseat driver (instead, ask to take the wheel!)
  • be bossy
  • be intimidated by partner's knowledge
  • be shy
  • be silent
    • about your ideas / questions
    • about your partner being rude