Why pair programming is kind of cool

If pair programming feels threatening at first, you’re normal. Two developers, one keyboard… yuck. If you’re like me, you want your own space, and you get a kind of rhythm going with mid-compile checking email and stuff. Taking that away during pair programming time sounds like it would be incredibly awkward.

Oddly, it just isn’t. When I first tried pairing intentionally, as a practice, it came rather naturally and wasn’t bad at all. It was actually fun.

My first big pair programming experience

This happened a couple of years ago, when I started on a fairly complex three-tier Web application for a really big manufacturer. The primary contractor had tons of domain knowledge and had already developed the DOS and then Windows versions of the same application, but now the client wanted this thing on the plants’ web servers… and she didn’t know enough about .NET and web tools to do it herself.

So we had two projects in one. The first project was the project: getting these new line-of-business applications done and rolled out. The second project was to transfer some development skills to… oh, I’ll just call the primary contractor Beth here.

Two really are better than one

You’d think that pairing slows you down, especially when the developers don’t have the same skills. Turns out, no, the fact that we had complementary skills made things much faster and easier than they would have been otherwise.

For one thing, Beth is a really quick learner, and she is very clear on what she does and doesn’t know. In short: “teachable.”

For another thing, she’d been maintaining this application on previous platforms for nigh upon a dozen years, so her domain knowledge was thorough. I on the other hand had a fairly vague idea of what this thing was really supposed to do.

But besides that, there really is some value to that “second pair of eyes” effect. When it was my turn to “drive,” Beth often interrupted with simplifying suggestions or hints that I was overcomplicating an algorithm. When Beth was driving, I frequently pointed or applauded. Sometimes the best thing about having a pair partner is the reassurance that you’re not messing things up as you go.

How it worked

A typical work day on this project alternated between pair and individual time, although on some days we worked separately and didn’t even see each other. We called those times “SWD” for “Separate Work Day.”

On SWDs, I’d try complex and somewhat experimental approaches to stubborn problems, and later present Beth with at least a sketch of the solution that worked. It didn’t seem like the sort of thing that would be amenable to pairing.

How well it worked

We got a tremendous amount of work done in a short time. Beth learned a ton about .NET, OLEDB, Oracle, and Ajax as we went along. Why did it work so well? Three main things:

1. As I said before, Beth is “teachable”; she picks things up quickly, and wants to.
2. The scope of the project was well-defined.
3. Our skills were divergent enough to learn and get things done, but not so far apart that pair sessions became remedial or tutorial in nature.

Lessons learned

I would totally do a pair project with Beth again. What would I do differently though?

Probably the biggest thing is something I stole from David Allen, the Getting Things Done guy. In his book by that name, Allen says something about choosing a task to work on based on “energy” of the moment. Sometimes you feel exceptionally ready to write, even though debugging might be more urgent. Or it’s “time to make phone calls” although you may have originally planned to do maintenance tasks.

Within reason, the thing you feel like doing is probably the right thing to do! You probably have a gigantic task backlog, and anything unimportant should have been stricken from your “GTD” lists already, so doing anything on the list is a great benefit. And you may as well choose the thing that has the most intellectual and emotional energy at the moment, because that’s the thing that will get done quickly and effectively.

In Agile terms, I guess that means sensing where your current “burn” leads and going there. Sometimes that will mean bailing on the pair for that day or hour. It’s fine, if that doesn’t break a deadline or make problems for your pair partner.

In a similar vein, pay attention to your choice of music and other surroundings. To her credit, Beth kept the Sirius Radio going most days. We flipped among a few favorite channels depending on mood, and she made lunch almost all the time. Oh yeah.

Long Story Short

I’m not–in this post–trying to convince you of the technical merits of pair programming. My point is that it’s nowhere near as awkward, uncomfortable, or frustrating, on a day-to-day basis, as it may seem if you haven’t tried it with a good partner. It’s easy to get started with and carries a low risk of failure because you can always pull back and do less if more isn’t working for you.

Have you tried pairing? How formally, and what were the results? How did you like it. The comment section is yours.