Pair Programming

Recently, I tried pair programming for the last project I was involved with. After a few months I have a some (mostly positive) things to report and a couple of suggestions. Basically, if you have been considering pair-programming then give it a try, keep what works and modify what doesn't but most of all read this post before you start (I wish I did!).

Often, the analogy of a rally driving team with a navigator and driver is used to explain the role of each person. When things are going well, I prefer to think of Pacific Rim when the pair is 'drift compatible'...

 but occasionally one person may 'chase the rabbit'...

"Are you really going to refactor that function ... again ... now?"

So, why don't more people pair program? Here are some reasons that people won't necessarily admit to:

• "If both are experts then you are wasting one developer's time, if one is an expert and one a novice then the expert has to waste time explaining, and if both are novices then their output will reduce by half!"
  
  - Pair programming with two experts has been found to reduce bugs by 15%. A greater range of solutions is also considered by the pair giving a fast convergence to the optimal solution. Novices will be brought up to speed more quickly compared to working individually.
  
• "I hate having someone watch me code - if I'm in the zone then I don't want to have to explain myself or be interrupted. If I'm doing something complex, I don't want to have to waste time defending my ideas"
  
  - The person watching you code may notice small errors and save a debugging cycle later. Subtle things such as the order of a case statement, confusing field names in a database, name clashes with referenced libraries etc. Also, explaining your idea often clarifies thought and may even indicate a wrong assumption in the problem domain.

Here I'll add some personal views and tips regarding pair programming that I have found:

• With pair programming you save yourself the effort of explaining your code to another developer because that developer watched the code as it happened. You both understand that code better than an English explanation could ever provide.
• With a shared understanding of the code you can communicate more easily  and precisely in regards to modifying or debugging.
• You gain more confidence in the code you produce.
• When one half of the programming pair is an expert, the other person has one of the best learning experiences they can get. You not only learn the usual coding syntax but also the workflow used - IDE choices and configurations, keyboard shortcuts, command line tools, open source libraries, the list goes on.

One aspect of pair programming that doesn't get talked about much is the impact of a coder's personality and coding style. I personally like to sit back for a minute or two and think hard about the code I'm about to write. Often I might plan a whole function in my head and then run it in my brain to see if it works - I don't like having the compiler or debugger tell me about things I should have already known. Other people like to leverage the compiler to highlight any trivial things while focusing at a higher level of detail. Another difference is top-down vs bottom-up programming, test driven design vs seat-of-the-pants and so on. When the pair is a little mismatched in their approach they may need to approach things with an element of patience and look at it as an opportunity to learn from each other.

I think the most important thing to remember is that there isn't one fixed recipe to pair programming - it will depend on the background of each developer. So give it a try, stick with it while modifying your approach to get maximum benefit and soon you'll be pushing category IV Kaiju kills to GitHub every day.