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?

Pair Programming: Introduction

I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.

First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.

Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.

I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.

I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.

I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.

The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.

Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.

On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.

I will cover some of my other thoughts in future posts.