I was recently forced into a pair programming exercise at work because we’d gotten to a critical bring up part of the code where nothing was really able to be done in parallel. Given that we are all noobs on this source base, there also wasn’t really anyone that should just go take the lead on it either. Given that 1 member of my team is actually in the same office as I am, we decided to try pair programming through it, because what else were we going to do. Jeremy brought in his laptop, and he mostly drove while I navigated as he was writing code. The results were impressive. In 2 days we got from a server that wouldn’t start, to one that was responding to half the nfs commands.

When first presented with Pair Programming most developers / managers have the same response: I’m going to have 2 people to do 1 person’s job?  That’s just crazy inefficient.  I admit, that I had my doubts, but as there is a decade of success behind this technique I decided it was worth trying.  The generic “it’s actually more efficient” statement didn’t sit well with me because there was not explanation behind it. The why it works is actually really interesting, and I think it also explains the types of problems it is good for and the ones it is not.

Anyone that’s developed software has run into programmers rut at some point.  This isn’t the same thing as writers block, it’s not the inability to create something, it’s having something not quite work and looping for hours to try to figure out why.  Typically it’s solved by going away from the code for a while (often overnight) and the solution is obvious in the morning.  When tackling a complex problem, you start building a model in your head that matches the software you are writing.  Sometimes you validate that model as you go, but often you don’t.  After hours working with that same piece of software you’ve made hundreds of assumptions on the model, any of which might be wrong.  But once it’s fixated in your head, tearing it back down to validate each and every step seems defeatist.  There is “just one more thing” that you could try and it will get you past this block.  How many times have you said that to yourself… just one more thing.  These “just one more thing” loops can easily become 4 hours in a shot.

When you walk away and come back, assuming your brain was focused elsewhere at the time, you’ve got to rebuild that model.  It’s not actually an exact copy of the model before, that’s why it takes time to get rolling on a complex software task.  And, as often as not you make slightly different assumptions this time, and low and behold you easily see where you were wrong.  Problem averted, and we move on.

But in pair programming, you don’t have 1 model, you have 2. At a superficial level, those are the same model, that’s the architecture of your project. But on a deep level, the level of actually assigning variables and doing test conditions in the code, those models are different. Those differences are why we enforce code conventions on software, because left to our own devices those differences in mental models would spill into the editors in somewhat surprising ways, making the software itself completely incomprehensible. Look at someone’s collection of private scripts they’ve written to automate small tasks, stuff they never intended to be shared, and you’ll see what I mean.

With only one person at the keyboard, and 2 mental models of the code in effect, you’ll get a nice amount back and forth when the 2 models don’t line up.  It’s kind of like unit testing for your brain.  During this exercise there was a lot of “wait, why are you doing that? … isn’t that supposed to be this other value? … are you sure that value is actually initialized in the called?”  I have no idea how many times I was right or wrong vs. Jeremy, it doesn’t matter.  What mattered is that we were constantly checking each other.  I mentally noted at least a dozen times where left alone, I would have been stuck for hours.  While not perfect (we had one rut that got us stuck for 2 hours because we’d both made the same bad assumption in our model), it seemed like we eliminated 90% of our ruts by having the second mental model.

And that’s where the efficiency comes from.  On anything other than rote code, software development is not continuous output.  It’s some number of hours hours stuck in a rut, then an hour of speedy implementation, then a new rut, then a burst…. rinse, wash, repeat.  It’s a set of fits and starts that as developers we convince ourselves was a much smoother process because we felt busy, or just because it’s the only way to do it.  But it turns out those fits are actually huge inefficiencies in the process.  They are probably one of the primary causes behind the observation that “great developers” produce 10 – 100x more output than average developers: great developers figured out how to pop out of ruts faster (either consciously or subconsciously). Pair programming gives you a simple tool to get some of that efficiency with your existing team and developers, making everyone a bit greater in the process.