Over a million developers have joined DZone.

Pair Programming Lessons from Improv

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of George Dinwiddie, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}