Pair programming

Most Hacker School alumni wish they'd spent more time pair programming during their batch. We learned this after the second batch, and have shared this fact with every batch since. Despite this, lots of people still tell us after Hacker School that they really wish they'd paired more.

What is pair programming?

Pairing means two people working on the same code using a single computer. The latter part – using only one computer – is important, because pairing is about actively collaborating and not just two people working on the same project or sitting next to each other.

At any given time, one person will be the "driver" and the other person will be the "navigator." The driver is the one sitting in front of the keyboard actually typing the code. The navigator sits next to the driver and reads the same screen. The navigator is there to talk through ideas, direct the driver, and think about how the code currently being written fits into the larger project. You should switch roles (i.e., driver and navigator) regularly, minimally every two hours, and ideally even more frequently. Switching regularly helps with knowledge transfer, ensures that both people get to drive and know what's going on, and helps keep everyone energized.

Sometimes you'll hit a wall. For example, you could run up against a concept neither person understands, or not know what library is best to use for your project. In these cases, it's ok to take a break from pairing. If you do this, you should time-box it, e.g., "Let's spend 15 minutes on our own researching what the best library for this is, and then report back with what we've found." The important thing is to explicitly agree to take a break and set a specific time when you'll check back in. The one thing you should not do is pretend to keep pairing but really default back to just working next to each other. It's easy to do this and waste hours without even noticing it.

There are several advantages to pairing. One is that it keeps everyone focused on the task at hand. When you're working alone, it can be easy to get distracted (e.g., by email or a shiny new JavaScript framework), but it's much, much harder to switch to Gmail when someone's sitting by your side and also reading your screen. Successful pairing should yield a productive feedback loop where each person helps keep the other focused.

Another advantage is that the navigator can catch a lot of small errors immediately (typos, missing semicolons, incorrect variable names, etc). It's faster and easier to fix bugs the moment they're introduced than at any subsequent time, so this ends up being a big win. Plus, as the saying goes, with many eyes, all bugs are shallow.

Pairing is great for knowledge transfer and can help with everything from learning a language to picking up editor or command line tricks.

Also, it's fun!