Play On

For years now I’ve heard about the benefits of pair programming. Pair programming is like coding with the buddy system. Instead of sitting at your own machine writing code by yourself, you and a colleague sit at the same box working together. I’ve heard that it’s faster than solo programming. I’ve heard that it produces fewer bugs. And I’ve heard that it’s just more fun. Last week I went to the Philly Emerging Tech for the Enterprise conference, and I heard even more praise for pair programming. We don’t do pair programming at drop.io, not out of dislike as much as inexperience. We’ve never really tried it.

So I tried it. Chris sits next to me, and we often show each other what we’re working on, so pairing with him seemed natural. It turned out he’d been curious too. We started on Monday, and now it’s been a week. So what have I found?

It’s all true. We blew through huge amounts of stuff. When you’re working with a pair, you can’t check your email every five minutes, or read Twitter, or watch YouTube videos. You stay on task. If one person gets up to get some water from the cooler, the other person can keep going. You catch all sorts of mistakes. I found these usually weren’t things which would become bugs, but they would have given us weird failures and taken longer to track down if we didn’t catch them immediately, like typos or forgetting to change the name of a method in one place.

Most importantly, though, we talked. When you’re working by yourself, it’s easy to just code and not think about how much time you’re taking to futz with a Rake task or implement a design pattern until— I’m late! I’m late! For a very important date! And as your deadline whooshes past you wonder where all the time went.

Working with a pair was different. We talked through everything as we did it, which meant we saw issues before went down rabbit holes. I felt extremely effective.

But there’s something else they say about pair programming, and it’s true too. It’s exhausting. Remember, you’re working full-steam, no futzing. It’s great while you’re doing it, but it’s easy to wear out. Always take frequent breaks when you’re pairing. You’ll still come out ahead, and—more importantly—you won’t keel over and die.

We also learned that some things don’t go well with pairing. Chris, being primarily a front-end guy, does a lot of styling and design. His CSS skills were useful in our pairing project where we touched the full stack from models to views. However, he’s working on some other things which are just design. Pairing there didn’t do much for us; it was mostly me watching him work. Pairing seems to work better when there’s more logical thinking to do.

We also found that the driver/navigator approach to pairing didn’t work well for us. Corey Haines in his (awesome) talk at Philly ETE said he preferred to give each person their own keyboard and mouse. That worked best for us too. We could switch typers rapidly, without moving the keyboard around.

Pairing is a habit. It is, I think, one of the Good Habits of Programming. Like TDD, it feels weird at first, then helpful, and eventually necessary. I can still code without a pair, just as I can code without tests, but why would I want to?