Tridge (of Samba fame) reviews a year of remote peer programming

There is hard data[1] that points to pair programming being much more productive than programming alone. This seems a little counter intuitive but if you dig a little deeper it starts to make sense.

First, programming isn't menial work. You have to think. Thinking is the hard part, typing just a realization of our thoughts. Removing one pair of hands from a keyboard doesn't reduce capacity by half. For teams that gel, it can improve capacity!

It also produces far less bugs. Another set of eyes on the screen is helpful. If you consider the fact that costs rise exponentially with regards to the lifetime of a bug, it makes sense to catch as many bugs as early as possible.

It seems to make developers happier. If that's not a goal in and of itself (I think it is.. but that's me), developer happiness surely affects the long term health and buy in of your employees (or co-workers).

There are several other reasons that come into play that are mostly discussed in [1] but also around the net. Just take a quick glance and you'll see everything you need :)

Now, granted, not everyone works well together and for some people it seems that they just cannot get along with someone standing over their shoulder. There are some ways to simulate pair programming but still be on your own. You can start "rubber ducking" your code. You can decrease time between writing code and getting feedback on the correctness of that code. You can act as your own reviewer by reviewing the code you wrote yesterday.

But, in my opinion, there is no better tool in my toolbox to get through a hairy refactor or complex domain logic than another like-minded developer sitting next to me.

[1] http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.P...

My limited experience of pair programming suggests that the biggest gain comes from having one brain devoted to the higher-level modelling and design task, and the other brain (with the hands attached) devoted to the lower-level intricacies of where to put the braces and semicolons, what headers to include to access which parts of the standard library, and so forth.

Because each brain can stay on one level without having to jump up and down the abstraction stack interruptions are lessened. Of course, if the higher-level brain starts to wander too far from the task at hand, the lower-level brain can interrupt, and if the lower-level brain gets tired of doing grunt-work, they can switch places.

That would be rad. I might chat to Tridge about it and see if they'd be willing to do it. :-)