I’m a big proponent of pairing now, but it wasn’t always this way. Before I joined Atomic, my only experiences pair programming were a few half-hearted attempts in college. After that I spent nearly eight years working on a programming project that came no closer to pairing than the occasional code review – unless you count sometimes having to walk someone through writing every line of the code I would later be in charge of reviewing.
Because of these experiences, I was fairly dubious about pair programming when I joined Atomic. Very quickly, however, I pulled a 180. Partnered with co-workers you can trust, pairing can produce amazing results, far better than you could working alone. And really, who wants to work somewhere you can’t trust your colleagues?
Pair programming can’t be beat when it comes to growth as a craftsman. I learned more about Test Driven Development in one day of pairing than in an entire week of reading about it. Moreover, it’s ideal for easing new team members into large and complex projects. What would take hours to learn on your own, wandering about the code like a disoriented tourist, can be accomplished much quicker by someone with a better grasp of the code. Better still, as you are learning, you are also capable of making positive contributions to the code. The benefits extend to the experienced team members as well. New team members bring a fresh perspective, and they can provide invaluable insights from their outside perspective.
Two programmers working together at the top of their game are a sight to behold. I recently switched from a solo project to a project with (some) pairing, and it felt like training wheels coming off, like I hadn’t realized the bike could go this fast. Or you might say it felt like pulling out of start-and-stop traffic into the high-occupancy vehicle lane. The more I think about it, the more I realize it’s no accident that we refer to the person who is typing as doing the “driving” – the car metaphor is very apt.
There are lots of ways that programming solo is like driving solo. As I mentioned, you simply can’t go as fast as a car in the high-occupancy lane. You can’t really keep a good eye on the road at the same time as you puzzle out the map – by which I mean that you will have a hard time paying attention to the little, immediate details like syntax at the same time as big picture ideas like code architecture. There’s no one to trade off with and take a turn when you get tired. Sure, you can crank the music up when you’re by yourself, but it won’t keep you as alert as another person to talk to.
By contrast, I think of effective pair programming as being like going on a road trip with a buddy. The camaraderie between the two of you acts as a natural mood lightener when things are getting stressful. Your co-pilot helps keep you from getting tunnel vision and losing sight of details on the periphery (“How might this code change affect other parts of the system?”). With two, it’s a lot easier to change tires if you spring a leak (dealing with an unexpected problem). It’s much safer with a co-pilot when moving about in complicated traffic (refactoring). And of course, you end up bonding with your co-pilot, which makes subsequent trips even better.
As must be clear, I have found pair programming to be tremendously fun and effective. I recommend it to everyone, if for nothing else than to shake up your coding habits and learn something new. When it comes to craftsmanship, we software developers are more like sharks than cars. If we don’t keep moving forward, pretty soon we won’t be moving at all.