I’ll take a slight detour from my usual “fact” based blog posts and focus on a matter of opinion, one that I have swung like a pendulum on myself, which is pair programming. Pair programming is something I’ve been using it for about 8 years now, and I think it is time I finally wrote some thoughts on it. My experience with pair programming has been “pair program 100% all the time”. If there is work to be done, we tried to pair program with it.

For those unfamiliar with pair programming, the gist of it is two developers, one computer. You have two (or four, six, etc.) monitors connected to a single computer, with two keyboards, two mice, and two developers work together to accomplish a goal.

Pair Programming Workstation

Naturally, this might seem a bit confusing at first, but the origins hark back to the days of Extreme Programming – XP for short – something that I was first exposed to in 2006. The two developers work together, writing the same code, helping each other. One person is doing the “driving” of the computer, while the other is watching for mistakes, providing input, or mentoring. Eventually they switch. Really, there are books on the subject of how to do pair programming, but that’s the single paragraph version of it. The uninitiated might first think, “Isn’t pair programming a tremendous waste of time?” Pair programming promises to make up on the additional use of a developer by offsetting it with increased quality. The argument is persuasive – bugs and defects are often the most expensive things to fix. If they can be limited during the development phase, and better quality and architecture is a result, then you end up with a net positive. You also have free knowledge transfer between team members.

Deeper though, there are too many problems with pair programming. I won’t argue that code quality usually ends up being better, and some bugs get caught. However the cost associated with the gains is too steep. I could just as easily require three people to code review work. That would also result in better quality. So increased quality cannot be the only deciding factor as to whether or not Pair Programming is successful for a team.

When I was first introduced to pair programming, I was a junior but capable developer. Pair programming really worked well in my favor. Rather than be thrown into a code base I had absolutely no familiarity with, I was working with people that had experience with the code, and working with a senior team member. As we were working together, I was not only seeing the code produced, but his reasoning and thought process behind what was being accomplished.

At the time, I didn’t think much of how the senior developer felt about pair programming. Eight years later, I have a pretty good idea – it’s hard. Being in a constant mentoring mode while being driven by hard deadlines is a constant act of balancing, one that after doing years and years of all the time, takes its toll. This “senior-junior” pair really only benefits a single person – the junior. This however detracts from the senior developer’s sense of accomplishment, which is something most senior developers thrive on. The senior developer’s goal is not to educate the junior person, it is to get things done. At worse, this can attribute to burn out to that senior developer. The list of potential issues goes on, from issues of engagement to personality.

I’m not writing this to shoot pair programming down. I just dislike dogma. There is a right time and a wrong time for everything, and applying a principle before a situation has been fully understood is asinine. Pair programming, like anything, should be understood if it is applicable in a given situation. Applying ad-hoc pair programming I think can be powerful. Rather than doing pair programming all of the time, asking a colleague for a few minutes or an hour of their time to work through something difficult is a totally normal thing to do.

I would even go so far any take it a step further and replace pair programming with actual mentoring and coaching time if you need to get a junior up to speed. If structured mentoring is put in place, the junior developer gets better results. The senior developer is focused on that, so it doesn’t detract from their sense of accomplishment, rather it contributes to it.