Mark Needham

Thoughts on Software Development

Pair Programming: It’s not about equal keyboard time

with 6 comments

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.

Be Sociable, Share!

Written by Mark Needham

May 23rd, 2009 at 4:35 pm

Posted in Pair Programming

Tagged with

  • Pingback: Nick Carroll » Blog Archive » The Navigator role must have been coined by a keyboard hogger()

  • Great points, Mark. I often get the feeling that many people who want to practice XP and Agile are looking for formulaic answers and rigid practices for how things should be done. This is precisely not Agile! The whole point is to do what works, not what is “fair” or “equal”.

    I also appreciate your point regarding the idea of “passivity” on the part of the person who is not at the keyboard. I find myself equally engaged in both driver and navigator roles. Each are productive in their own way.

  • Jeff! That’s exactly what I’ve been saying/thinking for the past year, being agile is doing what *works*! Finally, someone understands!

  • Pingback: TDD: Making the test green quickly at Mark Needham()

  • I believe that there are actually two types of experience level differences that can exist within a pair:
    1. Development experience/skill
    2. Experience with the code base that you are working in

    I’ve found that both can have an impact on how much I am able to contribute (regardless of whether I am a driver or navigator). One of the best ways that I’ve found to help bridge the experience divide is to have a 5 minute chat at the beginning of the pairing slot, focusing on things like:
    – The work that has already been done in trying to implement the solution
    – What the implementation options were/are and whether a path forward has been chosen
    – How similar/related stories/tasks have been implemented in the code base
    – What exactly an XYZWidget is and why/how it gets created by a FooBar

    A 5 minute chat accompanied sometimes with a quick whiteboard sketch can mean the difference between thinking to yourself ‘what are we doing here?’ and ‘so then we just need to do X and then Y….’

  • Pingback: TDD: Call your shots at Mark Needham()