Why pair programming is kind of cool

Pair programming is easy to get started with and carries a low risk of failure. Try it because it works, but also because you’ll like it.

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.

6 thoughts on “Why pair programming is kind of cool”

  1. Good post. I once worked for a large company where we “experimented” with paired programming. I found that the quality of experience you have has everything to do with the mindset of the people going into it. I truly enjoyed pairing with people who were driven to build good code, actually played the keyboard game and pointed things out as it went along. On the other hand on more than one occasion I would be pairing with someone who had absolutely no interest in sitting next to someone all day while they do their job. In these cases the pair generally shut off and I found myself doing all the work while the pair looked over my shoulder in a kinda creepy not helpful way.

    My advice is if your in an environment where pairing is the norm then you need to mentally get behind it and give it an honest effort. If you do you might find its no where near as bad as you thought it could be.

  2. Pair programming can be challenging and see potentially as someone watching over your shoulder. Many of our Agile teams at Suncorp use pair programming. We find it’s best to mix experienced with less experienced. This will bring the other individual up to speed much quicker and it’s enriching for the whole team. It shouldn’t be limited by technology or role type though. One of our highly regarded front-end development teams pair testers with developers for example to create automated continuous integration builds. In response to a question around pair programming on LinkedIn we got some interesting responses as well if you want to check them out at http://tr.im/CBDT.

  3. I used to believe in black-box testing, a long time ago–not sure why. Pairing with your tester is cool! It’s the ultimate white-box test.

    Now that you mention it, Josh, most Agile techniques depend on commitment and good will. You can make TDD fail if you want. You can turn Scrum into a Scramble.

    That’s the strength and the weakness (if you call it that) of the Agile concept. In touchy-feely emotional terms, Agile uses more of you than conventional methodologies do. Which means it’s not gonna work if you don’t show up… the same way counseling or poetry will come out badly if you’re resistant or resentful.

  4. It certainly helps that Beth is an absolutely wonderful person and a delight to be around. I’ve know too many developers that are the exact opposite. Teachable maybe, unbearable absolutely. But finding that rare pairing is great.

Leave a Reply

Your email address will not be published. Required fields are marked *