Adventures In Pair Programming

10 Must-Read Books For All Programmers

Imagine that you had someone looking over your shoulder at work at all times. Things that you do every day, like checking Facebook for a quick break or drafting an email to your boss, are different with a coworker watching. It may come as a surprise, but our company arranged that very thing. On purpose.

We're talking about "pair programming." While it's not widely practiced, most software developers are familiar with the concept. At its most basic, pair programming is exactly what it sounds like: two people working on the same problem, usually on the same machine.

Proponents of pair programming say it is a good way to improve code ownership, insure continuous code review, increase productivity, and reduce distractions (read: keep people on task). The main argument against it is that it is more expensive to use two people to do something one person might be able to do alone.

The one aspect that is often ignored in the paired programming discussion is how it affects learning. You'll soon see that the opportunities for learning may be one of the best arguments for paired programming.

The Decision to Pair: A Business Case

When we set out to develop our first cloud-based product, we knew that developing cloud-based software would require learning a completely new set of tools and processes, compared to the on-premises products we'd worked on in the past. We needed someone to help us expand our skillsets.

We chose Pivotal Labs, the consulting firm and incubator that helped start Twitter. Pivotal has a very important rule, however. They require pair programming. Little did we know, this was going to be quite the adventure.

[What will catapult your career to the next level? Read 8 Non-Tech Skills IT Pros Need to Succeed.]

Our pair programming adventure began each morning by picking a new partner from our team of eight people -- four from Perforce and four from Pivotal Labs. We practiced ad hoc pairing, developing with different people every day. Our team members ran the gamut of development experience, from the most junior to the most senior.

This diversity proved difficult to manage. By its very nature, the effectiveness of pair programming depends on the individuals practicing it. It leads to a lot of different personality clashes. Picture all the moods from Pixar's Inside Out.

The only issue we ran into was usually someone who stopped talking and coded on their own, leaving their partner hanging. This didn't happen too often, though, and was resolved without much intervention. While there were constant disagreements, they were usually constructive and led to good conversations about how to implement something.

Personally, it took me about a week to fully acclimate. The first day was the toughest, the next day was considerably easier. We all learned to adjust the process as we went along, but this led to one of the first roadblocks we encountered: project overload.

You know the scene in the movie The Fifth Element where Mila Jovovich learns everything she needs to know about planet Earth by scanning her eyes over a monitor? That's how fast you learn in pair programming. Okay, maybe not quite that fast, but with someone sitting next to each of us explaining new concepts in real-time (whether languages, processes, or tools), we all were in development overdrive.

This makes pair programming intense, especially at the beginning. At the end of the first day, I couldn't go home. Before I could face humans again, I put my phone on airplane mode, ignored my usual online accounts, and went to the gym for two hours of self-imposed isolation.

But the good news is that things got easier geometrically over the first week. By week two I was fully acclimated. I don't think this would happen to me if I did a full day of pairing again. Adaptation has become a skill that I'm confident I'll take with me to other environments.

Ironing out the Kinks: Finding Value in Pairing

As frightening as this sounds, the "togetherness" ended up having a tremendously positive impact beyond the initial goal of learning cloud development.

Pair programming forces teams to examine every feature from multiple angles and perspectives, something that's not possible with individual coding. You may think that collaborating through code reviews is an efficient system, but it's nothing compared to getting real-time feedback from the person next to you. Code quality vastly improves when you have to explain or defend your decisions, and when you're able to stop someone and have that person explain things to you.

Another benefit is something that can morbidly be summed up as a reduction in "bus value," the impact on the project if someone on your team got hit by a bus. Pair programming democratizes knowledge. Everyone becomes familiar with a variety of tools, processes, and project areas. While pairing takes an additional investment of time and resources, the organization is essentially spreading and increasing value across an entire team.

Taking It Back Home: One Size Does not Fit All

When we brought our project back to home base, we became a cultural outlier. We pushed pairing as hard as we could, but eventually we realized it wasn't a good fit for everyone. Ultimately, this led us to practice pair programming on a limited basis.

The takeaway from the experiment is that we now see pair programming as a skill, rather than a process to be implemented and reinforced from an organizational standpoint. If someone asks me, "Do you want to pair?" I can respond "Yes," "No," or "Why are you bothering me, I'm eating lunch?" We still pair once in a while, when a problem gets tough or we need a new set of eyes, but it's no longer the default or a required practice.

We came to pair programming expecting to become better developers, and we succeeded -- but not for the reasons we thought. We learned that being a good developer isn't only about speed or grasp of languages and methodologies. Good development is more social than we ever imagined. It's an opportunity to geek out with your coworkers and reignite your passion for your work, while also helping to evolve your skills and overall code quality.

If you are a CIO or development leader considering implementing pair programming, our experience shows that, instead of seeing it as an all-or-nothing policy, think of it as a skill for your programmers to acquire, and as a way to boost the knowledge of your whole team.

We went from being in a fairly isolated culture to being an extremely open and talkative one. Now, we're somewhere between those two points. Your own teams will need to determine where they're most comfortable working along that spectrum.

The more you can push towards collaboration the better off you'll be. If you think of it in those terms, it can be a success, whether or not your whole team turns full-time to pair programming.

Ready For A New Job?. InformationWeek's hosted, searchable job board can help you find your next gig. Start your search today.