I miss pairing (or the practice of paired programming). Those who have never tried paired programming commonly look at the practice as a waste of resources. Two people doing the work of one…or so it seems. However, there are so many things that pairing brings to the table. One of those is that when you pair program, things you would have to do anyways just happen. They get automated automatically (pun kind of intended). So let’s take a look at paired programming as a way to automate things you are going to do anyways (or prevent from happening).

• Automating of issue solving.
  
  As technologists, we face scenarios on a regular basis where we have to work through something that we haven’t done before, haven’t done in a while or just aren’t sure what the best way to do it is. When this occurs, our productivity can come to a crawl as we research the solution. With two developers, the likely hood that: a) one of the devs knows the answer or b) they can research the answer quicker cuts down on the time spent churning on a single issue.
  
  
• Knowledge transfer automation.
  
  This is related to the item above. When you work side by side with someone, you learn together. If one person knows something, they teach the other and vice versa. By rotating pairs, this transfer of knowledge happens automatically across your team. This limits the creation of SMEs and prevents bottle necks that occur when only one person knows a particular technology or part of the system.
  
  
• Automatic distraction repellant.
  
  When was the last time you were working in your cube and someone walked up just to talk? Unfortunately, (although no one will admit it) this happens way to often in the business world. This painful disruption of thought as well as the time taken away from development is a huge drain on productivity. However, when two or more people are already working together, people become less likely to interrupt. Those casual “Hey, did you catch the game last night?” conversations seem to just go away. People, by nature, are less likely to interrupt a pair of developers working than just a single developer. Just another place where there is power in numbers.

So how about it? On paper this makes sense. Those who have tried it seem to agree. However, why is it that this practice seems about as likely to go mainstream as cutting overtime (which many studies have proven actually makes developers less productive…a topic for a different day)? What are your experiences with paired programming? What’s good, what’s bad? Share your thoughts in the comments!