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 wrote about ping pong pairing, including an approach to ensure that both members get exactly the same amount of keyboard time per day.

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 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.

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.

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.