One thing that I often forget is that when you’re driving you know exactly where you’re going with the mouse or keyboard just before you do it whereas the other person doesn’t know until you’ve done it.

As a result of this it is useful to commentate on what you’re about to do and not move around the code at break neck speed, but instead take your time and pause after each step to allow your pair to follow where you are in the code.

It seems like this might slow you down but I find that quite frequently when I race around the code in this way I’m making assumptions about the code and I didn’t even know that I was doing it.

Having someone else working alongside you forces those assumptions out into the open and it’s amazing how often you end up going a different way than you had originally assumed.

Moving through the code more slowly is especially important if you call someone over to help you with something since in this situation they have very little idea about what you’re doing so they won’t be able to provide much assistance unless you take the time to provide the context to them.

Another trap which is best to avoid is always thinking that you personally have the solution to all the problems the pair encounters and that your solution should always be the one used.

I think this becomes a particularly easy trap to fall into when you’ve learnt a few ways to solve problems and the temptation is to always use these solutions and block out suggestions which we judge as being inferior to our solution.

This seems similar to Jay Fields' post 'Kill your darlings' where he describes a technique George Malamidis taught him:

I noticed that when working with my colleague Lu Ning I wasn’t very keen to understand his ideas about how to structure code and move data between the client and server sides because I was convinced that the way I already knew would work better.

As it turned out when I eventually started listening I realised that his approach worked much better than any ideas I had so he taught me something new.

This situation comes up a lot when pair programming and I think it’s useful to always keep an open mind - that way you might learn something you didn’t expect to.

I think this one is more obviously ineffective and I don’t think I do this as often.

I did suggest in another post that getting control of the keyboard can be a useful way to help you become more engaged in a pairing session, it’s certainly useful to ensure that you communicate why you’re doing that and checking if it’s ok with your pair if you drive now.

On the other hand just grabbing the keyboard and typing without saying anything because you think you have a 'great idea' is not really an effective way of working together with your pair as it effectively sidelines them.

These are just a few observations of some things I’ve noticed and as always there are no doubt more ways that we can pair program ineffectively.

Pair programming for me is not just about putting two people together and having them work the same way they would normally - there certainly seems to be a completely different dynamic to the way we work and I think it’s important to adjust the way we work to adapt to that.