· pair-programming

Pair Programming: It's not about equal keyboard time

My colleague Nick Carroll recently blogged some ideas about what to do if your pair is hogging the keyboard, suggesting using a timer which keeps track of how long each person has had at the keyboard as a useful way of ensuring that both people in the pair stay more engaged.

While I can see the thinking behind this I think it is addressing the wrong problem.

From my experience we don’t always want to be moving the keyboard between the two people quickly at all times - I have certainly seen times where it makes sense for one person to be spending more time at the keyboard than the other.

A particular example of this is when there is a difference in experience between the two people at the particular skills required to complete the task they’re working on.

On a project I worked on around 18 months ago I was struggling to stay engaged as the navigator as I didn’t really understand what was going on and the half/half split in keyboard time wasn’t really helping.

Chatting with a more experienced colleague about this at the time he suggested that when I paired with him he was perfectly happy to spend the majority of the time navigating while I drove so that I could get more understanding around the code base and become more useful to the team.

This colleague was clearly keeping the big picture in mind and I haven’t come across a situation since then where someone acted so selflessly for the benefit of the team.

The lesson for me from this situation is that sometimes it makes sense for the person who can gain most from driving to do so more frequently.

The other thing I think Nick’s post is suggesting is that the only way for you to be engaged in a pair is when you are at the keyboard, which I don’t believe to be correct.

The role of the navigator shouldn’t be underestimated as when it’s done well it provides a very good complement to the person driving as that person is taking a bigger picture view of what the pair are working on and ensuring that the code being written is still fitting in with the rest of the system. Dahlia has written an informative post about some of the things that she does when navigating in a pair.

Another idea Dan suggested to me is to commentate on what you think is happening/what the other person is doing at the keyboard when you’re navigating and feeling a bit lost.

I’ve spent quite a bit of time working with Lu Ning on some Javascript on our project recently and have been trying out this approach there and I think it’s helped me to understand things better although clearly it takes a lot of patience from the driver if you take this approach.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket