Pair Programming: Some thoughts
Mark Wilden pointed me to a post he’s written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations.
When you pair program, you’re effectively joined at the hip with your pair. You can’t pair if only one of you is there.
I’ve previously written wondering what we should do if our pair isn’t around where I was leaning more towards the opinion that we should try to continue along the same path that we were on when working with our pair if they’re gone for a short amount of time and to find a new pair or work alone if they’re gone for longer.
On the projects I’ve worked on we’ll still have times working alone when there’s an odd number of people around or if someone just feels like working on their own and I think that’s fine as well. I don’t think we need to pair 100% of the time.
You have to be able to think out loud - 8 hours a day. Then you have to type in code while someone is watching you. They’ll catch your typos (hopefully after giving you a chance to spot them yourself) and they’ll see when you’re floundering for how to do something.
I find that this is quite a useful practice for explaining things to yourself although I can see how it would initially exhausting.
Even now there are times when I just want to write some code instead of having to explain what I want to do to someone else. Sadly almost every time I explain something it turns out that my pair has a better idea of how to do it than me so I’m always glad pairing encourages this conversation.
Pair programming doesn’t encourage quiet reflection and exploration. You can’t just sit back and read some code. You can’t just sit and think. I mean, you can, but then your pair is just sitting there.
This is a bit of a double edged sword - pair programming does encourage us to get things done but it’s also true that sometimes we need to get the whiteboard out.
Often just sketching out the problem on a piece of paper to check your understanding is enough to trigger a conversation which might result in a better solution.
It does tend to need one person to drive this process though. I haven’t seen it just happen organically.
We rarely pair 100% of the time so there are often times when you get a bit of time to play around a bit with the code and see whether specific approaches would work out and I often use this time for reflection and exploration.
One thing which a couple of the commenters on the original blog suggested is that perhaps more rotation was needed to help overcome some of the problems and from my experience it’s vital that we do rotate otherwise the pair will end up hating each other!
I recently worked on a story with 3 other people across its life and each person pointed out something that I hadn’t previously considered and which led to an eventual output that was much better than it would have been otherwise.
I think rotating different people onto a story can help lead to more innovative design as long as we have people working together who are relatively flexible and open to trying out new ideas.
Mark’s post is certainly interesting though and helps identify some of the things we need to be aware of when pair programming - we don’t just want to follow the practice blindly.