Pair Programming: Observations on anti-patterns
I’ve been pairing a bit more regularly recently after more sporadic pairing sessions over the last 9 or 10 months and I’ve noticed that I’ve picked up some habits which aren’t really that effective when pairing so I’m on a mission to sort that out.
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.
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 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.
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.