I read an interesting blog post by Mark Needham today that talks about some anti-patterns he found himself falling into while pairing. I have also caught myself being guilty of some of these offenses so I thought that listing some here explicitly will help keep it fresh in everyone’s mind. Of coarse what works some may not work for everyone, but here is a small list of behaviors I which I find can negatively impact pair-programming…
Moving around the code too quickly
As the driver, it is normally a bad idea to be changing windows/files/tabs/etc. too quickly while you are in control of the computer. It is easy to forget that your navigator may not know what you are thinking so you find yourself flying through the UI of your workstation at lightning speeds only to have your pair say “Ok… what just happened?” Granted, following a driver’s every keystroke is not the navigator’s concern, I do find it helps collective code ownership to have the navigator pay attention to what the driver is doing. Therefor, I believe that it is always a good idea to communicate to your navigator what you are planning to do BEFORE doing it which also give them the opportunity to offer any input they have before everything has been said and done.
Grabbing the keyboard away
This one is a little more obvious as to why it is an anti-pattern but let me elaborate anyway. My opinion is that it is NEVER a good idea to take control of the keyboard and mouse without asking first. I have seen it happen for various different reasons; lack of time, lack knowledge, lack of patience, lack of discipline, and lack of respect. Sometimes you just want to finish your task and you know you can get it done quicker or maybe you are really excited about trying to solve the problem and hand and anxiously snatch control of the computer. Sometimes the guilty may have all of the above reasons for this behavior but I don’t think it should ever be acceptable. By taking control, you are giving your pair the impression that you think they can not accomplish what needs to be done or that you can do it better. It is always a good idea to ask first before taking control and if the driver was in the middle of something, you’d better have a good reason. This also promotes better communication because you more often have to attempt to explain your ideas to your driver instead of just doing it yourself.
Vacationing as the navigator
Pair programming often come with negative connotations because some ask “Well what can/should I really do as a pair?”. The reality of it is that pair-programming involves two distinct roles each with their own very engaging responsibilities. The driver is tasked with controlling the workstation to write the test cases, code, and refactor. The navigator should be involved with design decisions made while writing the code but they do not necessarily have to be reading every line of code the driver writes. Instead, they should be thinking of what test cases come next, whether or not the existing tests are passing, can we commit, and most importantly: “Are we done yet?”. This is why it is very important to not become detached from the task at hand while your driver tries to figure out where he is missing a semi-colon. Distractions like mobile devices, food, twitter, etc. can often lead the the navigator not having a plan which leaves both people in the pair asking “What next?”. This is not to say that a driver cannot become distracted as well but, in my experience, I have found it harder to fall into the trap when you are the one engaged at the keyboard and much easier when you can literally twiddle your thumbs. Just remember you are there as a supportive role to your driver and they are lost without your “map”. To help avoid this, it is a good idea to make sure you are switching roles often to keep both people engaged in the task at hand.
You can check out the original blog post which inspired this one here.
You can learn more about pair-programming here and here.
I am also interested if anyone else has any other pair-programming anti-patterns they would like others to be aware of. What do you find negatively affects a pair-programming situation? Or for that matter, any tips on how you have become more effective? Feel free to share!
