As part of NYC Comedy Fest, I went to see the writers of Colbert Report speak. It turns out that every day after the topics that they’re going to work on are chosen, they split up into pairs to work through the jokes.
The team of writers discussed how pairing up encourages conversation, helps them tests the way a joke will sound, and prevents writers block. They discussed how it helps them focus, catch grammatical errors, and generally produce more laughs. Hearing them espouse the virtues of not working alone reminded me of how we talk about paired programming at Pivotal.
It made me wonder about other examples of pairing, like co-pilots on a plane or rock climbing buddies where two people working together are definitely better than one. Then I was reminded of and another form of teaming up from my childhood which I’ve now come to use as the fastest explanation of how Pivotal develops software to old friends.
When we talk with prospects, clients, and recruits about our flavor of software development, it’s often the first time they have seen paired programming. As they watch Pivots develop software, they quickly see why it works and how it will help their project. Though there is much debate about paired programming’s advantages, it seems two people working together is successful in many arenas.
The first thing people notice is that by sharing a computer and switching off who is typing, developers are forced to talk to each other. Upon deeper investigation, it becomes clear that through conversation the easiest solution often surfaces.
Beyond other benefits, in the same way the comedic writers avoid writer’s block, working on tough development problems is more productive with someone else. And if you’re really stuck, once the ego is removed of one person having to provide a solution, developers are more inclined to ask other pairs for help.
The Colbert Report writing staff got me thinking about other situations where I had been exposed to pairing. I went to a Jewish community high school where we studied talmudic texts. It’s traditional to do what is referred to as “chavruta” learning, where each person has a buddy with whom they work through understanding the documented debates of the rabbis.
One of the tenets of this ancient form of learning is that it prevents someone from going down the wrong path for too long. The system challenges the student to verbally explain their perspective, question their partner’s reasoning, and often arrive at new conclusions. The parallels to flying a plane or climbing a mountain are easy to make. Similarly, at Pivotal we see how paired programming stops cowboy developers from implementing complicated code that may not be the simplest solution.
Recently, as our product and design teams have grown at the NYC office, we’ve begun pairing as non-developers. I’ve had multiple new PMs shadow me on a pairing station, where they can see my work email and projects in Tracker. It’s beneficial to them to see what’s happening without leering over my shoulder and soon they even contribute on the second keyboard.
An extra set of eyes can be incredibly helpful at making sure a user story is complete. My partner can catch a typo, make sure the description is clear, or check that all necessary acceptance criteria are included. After pairing on my project’s backlog with a newly hired PM, I conducted the smoothest iteration planning meeting I’ve ever had.
Our design team has also been pairing more recently and found it very effective.
Share a story of how pairing worked for you! Or… read some more examples of pairing success to be inspired.
