Green Moon Software, LLC

Some Thoughts on Pair Programming

Two programmers, one computer. To management, it sounds like waste. To agile mentors, it sounds like the answer. What does it sound like to developers? The answer (as with most things) is “depends”.

I have only been pair programming for a little over a year. Prior to that, the majority of my career has been spent alone in a cube or office.
In 2001 when I started in my first job, we did something like pair programming. Obviously, it was not called that at the time. It also did not look like today’s pair programming. It consisted of me sitting next to a more senior developer while s/he wrote code. I would help dictate requirements and help transpose. It was still two eyes on one screen. This style of work helped me get learn the system, but it didn’t really help me learn to program.

Fast-forward to today. I am in a position that pairs 100% of the time. We switch pairs after every 2 week iteration. One developer usually takes the keyboard in the morning, and the other takes over in the afternoon. We sit at large tables with a single monitor between us. We each have our own laptops and simply switch the video cable for the monitor. This allows us to setup our own computer to suit our unique needs (ie: plugins, keybindings, etc). It also allows us the ability to turn away and check emails or text messages on occasion.

After working in this environment, I have seen how well it works to get new hires integrated with the software. I have seen how it helps fresh graduates start learning the “right way”1. I think about all of the missed opportunities from my past career with regret.

In addition to the two benefits described above, it is also beneficial on new features or working around critical components. Two sets of eyes are better than one.

However, pair programming is not a silver bullet. I feel it does not work for every company or situation. Production support is one such situation. Often times tracking down bugs is a hunting mission. Lots of different paths have to be explored to find the bug. Pairing will only get in the way here.

Simple feature enhancements usually do not require a pair. These features are fairly simple and straight-forward. They do not touch critical components. Pairing on these types of features is a waste of time.

In conclusion, I am not advocating NOT pair programming. I advocate to use it in the correct situations and not just simply applied as a constant practice. I highly recommend doing pull requests prior to integrating any code into the main branch. This will allow a second set of eyes to review code. I also highly recommend writing tests. In my opinion, these add up to more quality than 100% pair programming.

1 Obviously, there is no one “right way” for everything. But there is usually a lot of predisposed teaching that needs to be undone to most fresh graduates.

comments powered by Disqus