Pair Programming: Keeping both people engaged
I’ve written a few times previously about pair programming and how I think it’s one of the best practices I’ve seen used on agile teams but in order to ensure that we’re making the best use of this practice it’s important to ensure that both people are engaged.
It is often quite difficult to persuade people who aren’t used to extreme programming that having two people working at the same machine is actually beneficial and this task can be made even more difficult if one person is losing focus or interest and therefore isn’t actually adding much value in that pairing session.
Who’s responsible for making the pair function well?
In all likelihood the person who’s not currently at the keyboard is going to be the one losing focus and in this situation I often wonder whose responsibility it is for ensuring that the pair is functioning well.
My initial thinking is that it’s the responsibility of the person driving to bring the navigator along with them and that if this isn’t happening then they’re not doing a very good job in the driving role.
A fairly typical scenario is for the driver to be coding and not really saying anything to their partner while they’re doing so, therefore internalising all the mini decisions that they’re making.
Vocalise your thoughts when driving
When I was first shown how to pair program we were taught to vocalise everything we were doing while at the keyboard, thereby pretty much providing a running commentary for our pair to allow them to follow what we were doing.
This commentary could be anything from detailing a refactoring that we’ve seen and want to perform to asking our pair for help to understand a bit of code that we’re finding tricky.
Hopefully this commentary helps create an almost constant conversation between the two people pairing.
If the driver isn’t providing this commentary then an idea which Dan North suggested to me is that the navigator can try and get this conversation going by commentating on what their pair is doing or by asking them questions.
I suppose done to an extreme this might be a bit annoying but it should only be necessary to do this for a short amount of time until the driver starts being more communicative and I’ve found that it works quite well as a technique for getting yourself engaged again.
Another approach is to get back control (with your pair’s permission!) of the keyboard and continue where your pair left off until you have regained the context that you previously lost at which stage you might hand the keyboard back.
It might also make sense to take a break for a few minutes and walk around or get a drink before returning to the pair - I find that this works well for me too.
Doing something is better than doing nothing
The key here is that once we identify the problem the worst thing that we can do is to do nothing. The current situation clearly isn’t working for us so we need to do something about it.
As I learnt when studying NLP:
If what you’re doing isn’t working, try something else, anything else, regardless of whether what you had been doing should have worked.
While discussing some of this ideas with my colleague Lu Ning he suggested that if we are losing focus then it might be an indicator that we should split up the pair.
I think we should still look to try some of the above ideas but if they don’t have any effect then Lu is probably correct.