Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.

How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.

A few years back, I took a course in “Beginning Improv Acting.” I don’t plan to make a living performing improv theater, but I thought it would be beneficial for becoming more comfortable and competent at public speaking. It did that, but it also taught me some deeper lessons about collaboration, some so deep I can’t yet articulate them.

When performing improv, the flow on the scene might go in any direction, but it definitely won’t go the direction that you have in mind. No one else can see what’s in your mind, and they’re not working off your script. If you try to constrain them to your script, the scene quickly comes to a halt. In the class, we had one student who frequently caused this, and, while I learned how destructive this behavior is to collaboration, I also learned to avoid doing scenes with her whenever possible without being disruptive.

Instead, a big key to successful improv is to provide the other person with as many options as you can. You want to be detailed and concrete with your contribution to the scene, but without requiring a lot of baggage that hasn’t yet been made explicit. I found it helpful to avoid thinking too far ahead, as I would get attached to my story line instead of our story line. By providing options to the other people in the scene, I was also providing options for my future self. And I was encouraging them to maximize the options they provided me. The resulting explosion of possibilities made every improv response much easier and more natural. It was a lot of fun when we achieved that level of flow.

Pair programming with test driven development is, for me, exactly like that. When I’m pairing with someone who wants the code to go in a particular way, or when I want it to go in a particular way, it breaks the flow. Sometimes having a short design discussion leads us to agree on that particular way, and that usually works out OK. But the best pairing is when neither of us looks too far ahead, but writes the immediate concrete specifics of the moment. We trade frequently and excitedly, going in the direction that seems obvious. We achieve flow as a pair, and move quickly toward our functional goal.

Perhaps not everyone can work this way. Some people claim that they can’t work in a pair. I suspect that, more likely, they and/or their pair just haven’t developed the skill, yet. And you can only develop this skill by trying, and by practicing.