One of the hardest situations that comes up when pair programming is when you want to solve a problem in a certain way but you can’t persuade your pair that it’s the approach you should take.

The temptation in these situations is to wait until your pair isn’t around, maybe by staying late at the end of the day or coming in early the next day and then making the changes to the code that you wanted to make but didn’t when you were pairing with them.

My colleague Cam Swords has coined this pattern of behaviour 'the code fairy' and it’s something that we want to try and avoid in software development teams.

The thing to note here is that you’re following another direction than you had been when pairing, not that you’re working alone on the code just because you’re pair can’t work with you at the moment for example.

The problem with following this approach is that you lose the benefit of pairing in that you have two eyes looking at the code and reducing the likelihood of stupid code being put into the code base - by stupid I mean code which has been written with cleverness in mind rather than simplicity. I find that when I work alone those types of ideas are much more likely to seem a good idea than when I have someone else there to put me right.

When we can’t convince our pair to follow our approach it is often due to the fact that we can’t articulate why we prefer it well enough to convince them. In a recent conversation with Cam about the problem of persuading people of our approach he pointed out that even if we are really good at constructing an argument for why our approach is better our pair may still not want to do it and we can’t do a lot about it.

Most recently I’ve been really enthused by the idea of writing functional OO code but I find it very frustrating that I can’t currently clearly explain why I prefer this approach to writing code over an approach which favours there being more mutable state.

I really want to go and change the code to follow that approach but it would be inconsistent with the rest of the code base as well as being less clear to my team mates since it would have been me who wrote it alone rather than doing it in collaboration with a colleague.

Another problem is that since we ended up going and re-writing the code ourselves the same situation will happen again in the future so we haven’t really achieved anything apart from temporarily making the code a bit better in our eyes. In addition there are now less people on the team who understand that particular bit of code which is not a good position to be in when we’re working in a team.

It’s definitely not easy to resist the urge to go and 'fix' the code on our own but for the benefit of our team mates it’s something we need to consider.