Pair Programming: The Non Driving Pair

One of the intriguing aspects of pair programming for me is that of the non driving person in the pair – what are they supposed to do?!

Obviously there are fairly well known strategies for more interactive pairing, such as Ping Pong and Ball and Board (which is where one person controls the mouse and the other the keyboard), but neither of these strategies suggest what to do when you are not driving

Obviously it is very easy to be a bad non driving part of the pair, by getting distracted by what’s going on around you and a quick fix that I’ve heard to solve this is that when you’re bored, ask for the keyboard back. This solves the immediate problem but still doesn’t make you any better at contributing when you’re not at the keyboard.

One idea that I’ve been playing with recently is keeping a list of the next task that needs to be done after the current one is done – effectively just tracking where we are on the story. We use tiny tasks for most stories as laid out by Patrick Kua. This does work although you still don’t feel that involved, and it can end up seeming like you’re dictating to the other person what to do. This is definitely an approach to be applied with some tact.

Some of the more skilled non drivers I’ve worked with have the ability to see the bit of code being worked on as part of the whole and are able to see when we have gone too far down the wrong path and should actually be making changes elsewhere. I find this a lot harder to consciously improve, and I’ve been told it’s a skill that comes with experience.

I’m sure there are other roles of non driving that can be applied, mentoring being one, although that’s for another post! Thoughts?

Be Sociable, Share!
  • Pat

    See if you can track down a copy of Pair Programming Illuminated. It describes different styles of pairs working together and when pairing works against instead of for.

    I have a few suggestions for improving your skill as a “navigator” (another name given to the person not actively coding).

    Rather than just dive into the tiny tasks – have that design discussion with your pair about what is the best way of approaching whatever you’re working on. A result of this might be tiny tasks. If it’s straightforward, then you can simply review the tiny tasks.

    When you’re not driving I find it’s useful to step back and ask a few questions to myself. Is the testing strategy right? Is there excessive duplication? Would some other person come along and find this difficult to follow? Does it look consistent with the way the rest of the application? Are there more tiny tasks to find and add to the pile?

    One other thing I find useful to do when acting as a navigator is to share tips around the workspace such as keyboard shortcuts, various tools (I see you do this – did you know you could do it quicker if you used x?).

    If you don’t find yourself adding value or if your pair doesn’t feel like you’re adding value then maybe you should reduce the amount of pair programming time.

  • Apurv

    I was in a peculiar problem and ThoughtWorks University last week. It was my first week and I came up with a problem. How do you involve a person in the whole process of estimating. If a person is not giving his ideas, feedback and gives only when asked this question “what do you think about this?”. How to cope with this, do the safety check more often, keep asking the questions or talk to person outside.

    What if somebody is feeling isolated? How as a developer I can make him/her a better part of the team. These are some of the questions that came up during the Lego Game at TWU.

  • Pingback: Pair Programming: The Over Eager Driver at Mark Needham()

  • Pingback: Pair Programming: It’s not about equal keyboard time at Mark Needham()