Pairing as a way of life

Hashrocket has a few core philosphies that are essentially required for team members. Agile development processes, an adherence to ruby and rails best practices and idioms, and a firm belief in pair programming are three of the biggies. Of these three, pair programming is the technique that has changed me most, and required the most change in my thinking. And not surprisingly, pair programming has proven the most critical to my success at Hashrocket.

I knew of pair programming before I came down to check out the Hashrocket way. And I even knew some people who personally advocated pairing. But I was that guy. You know, the one who does his best work in the morning with his headphones on and drinking an obscenely large coffee. The guy who types madly for a few select hours a day and, during those few hours, produces as much as regular-speed developers do over the course of a day.

There was definitely a transition period when I would only have a pair for half a day here and there where I was still that guy even though I was with Hashrocket. But ultimately, I have come to realize three distinct situations in which pairing is far superior to working solo that have cemented my belief that pair programming is superior to solo programming.

First, a big part of coding is constantly seeing the big picture. I can't tell you how many times I've sat down to solve a problem and been blind-sided by a particularly difficult routine to write, or maybe a supremely complex data model. Or maybe I find that I have to monkey-patch some existing code. These situations inevitably make me sit and spin my wheels for a minute... sometimes they even made me get up out of my desk and waste some time thinking about solutions. Occasionally I would give up and leave early for the day. With a pair sitting next to me, however, a simple discussion of the situation typically leads to a more obvious solution. In worst case scenarios, we are still more productive by keeping different parts of the solution in each of our heads.

Other times, that obscenely large coffee is just a bit too much and I get going a little too fast. I make simple typos or logic mistakes that I don't catch until I've already started running tests, and then I end up wasting 30 seconds waiting for tests to tell me that I've entered a period instead of a comma. As an over-caffeinated developer, I can't tell you how frustrating these little typos and large amounts of wasted time become. With a pair by my side, it's very rare thing that I get to the end of any line of code without one of us noticing a typo.

The last situation that I've noticed an improvement in development speed while with a pair is after lunch. I don't know about anyone else, but I get very yawny after lunch. So instead of spinning my gears alone and staring off into space, my pair and I typically find myself getting into more code discussions, or letting my pair drive while I keep an eye out for typos. Either way, I'm way more productive than I would be while browsing digg.com.

For all of these reasons, I've become a huge believer in pair programming. And since becoming a believer in pairing, I've found myself extending the idea of pairing to other areas of my life: I pair at the gym with my gym buddy, I have a haircut buddy, and I typically line up my schedules for things like DMV runs with other folks.

But the real reason I wanted to talk about pairing today was my latest pair adventure: presenting. I'll be honest; I think I'm a terrible presenter. There was a time in High School when I won awards for giving speeches. That was almost a decade ago, though, and I'm a little more than frightened about getting in front of a large group of people.

Being at Hashrocket, it's no surprise that I'm surrounded by people way smarter than me. In this situation, having a more senior pair is quite possibly the best thing I could have asked for in my career. And also, being part of a brain trust such as we are, it's only natural that all of us Rocketeers should be presenting at a few conferences a year. And let me tell you, I'm not the only Rocketeer terrified of getting up in front of a crowd.

So my solution: present two topics at once in a stream-lined talk about two different topics. Jax CodeCamp is coming up, and I'm hoping to present a talk discussing distributed development with git and rapid web application development with rails. As a side effect we'll also be discussing pair programming, but that should be in a mostly meta sense. The idea is for one of us to create an application and commit it to a git repo and from then on to ping-pong back and forth, making incremental application improvments and highlighting the uses of git in distributed development while we do so.

The benefits of doing so should be two-fold: first, to show how awesome ruby on rails and git can be, and second to decrease the likelihood that either me or the other speaker will run out of the room screaming.

Wish me luck?