Pair Programming: The Over Eager Driver
Date: 2008-11-05 23:48:54

One of the interesting situations that can arise when pair programming is that one person dominates the driving and their pair can hardly get a look in.

This is not necessarily because they are hogging the keyboard - it is often just the case that they are the stronger technically in the pair and the other person isn't willing to ask for the keyboard.

A big part of the value in pair programming comes from having both people taking turns at driving and navigating from my experience and there are several ideas that I have come across for trying to encourage a more collaborative approach to pair programming.

== Ping Pong Pairing

The idea of this approach is to encourage the switching of the keyboard between both people very explicitly.

Based on the assumption that we are adopting a TDD approach, the first person starts out by writing the test, then they switch and the second person writes the code to make the test pass. Then they write the next test and the first person writes the code to make that test pass.

With this approach both people end up with fairly equal keyboard time and will hopefully feel more involved in the development effort.

My colleague Sam Newman previously http://www.magpiebrain.com/blog/2007/02/13/pairing-pattern-ping-pong-pairing/[wrote about ping pong pairing], including an approach to ensure that both members get exactly the same amount of keyboard time per day.

== Learning the Art of Navigating

As a general rule I think the majority of people find it much easier to drive than to navigate.

When navigating it often feels that you are not adding value and it sometimes becomes confusing as to exactly http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/[what you should be doing].

Having said that I have worked with some phenomenally good navigators during my time pair programming. While I don't claim to know how to teach someone how to be a good navigator (I'm still working on it myself), there do seem to be some distinct skills that you can apply to carry out this role effectively.

* Keeping an eye on the big picture - are we solving the right problem, has this piece of code become too difficult to test, are we testing it in the correct way etc.
* Tracking the tasks needed to complete a story and being ready to continue with the next one when the driver has finished the current one.
* Sharing tips on how to navigate around the workspace more effectively - keyboard shortcuts, different tools etc.

If we can become equally effective at contributing as both a navigator and a driver then it doesn't become so imperative to drive all the time.

== Two of everything

This was an approach I was introduced to more recently and involves having two keyboards and two mice connected to the workstation.

The benefit of this approach is that the difficulty of prising the keyboard away is removed and we can just grab our own keyboard and start typing when we have some input to make.

Clearly this needs to be done relatively sensibly otherwise otherwise we end up with both people typing or moving the mouse at the same time. From my experience of this technique that actually rarely happens.

There is also an increased spending on equipment but I wouldn't imagine this would be that significant.