Two Heads are Better Than One
Week 5
Examining the Benefits of Pair Programming
October 17, 2014
When you ask someone to imagine a computer programmer, they’ll most likely come up with the image of a lone coder toiling by themselves for hours in a darkened room. But that caricature, especially recently, is pretty far from the way many programmers work. Today programming is often a collaborative task, and most professional web developers work closely in teams. Pair programming is an increasingly popular way to collaborate and develop strong code, especially for beginners.
Pair programming – working directly with one other person while you write your code - helps you create more robust programs, work more productively, and learn more quickly. My experiences with pairing so far at DBC have varied quite a bit, but I have learned from all my sessions in one way or another – and often in surprising ways. Whether I’m in the position or learning or teaching, I’ve found that having two people contribute leads to a stronger final project.
Pair programming is normally divided into driver and navigator roles. The driver writes the majority of the code, while the navigator tells them what to write. I’ve found these roles very helpful (once I got the hang of them) because they helps structure an intimidating task – each person knows exactly what they’ll be doing. Navigating helps me focus on the logic of a problem, while driving is good practice for syntax. I like to switch roles at some point during a problem to get equal experience with both logic and syntax.
Communication and feedback is crucial to a successful pairing session. Both members of a pair have to be confident that they’ll both benefit from the session and that their partner won’t jeopardize the session by, for example, being uncommunicative, overbearing, or going off on a tangent that doesn’t benefit the pair. My first few pairing sessions were somewhat intimidating and I wasn’t comfortable with the feeling of always being on the spot. But my pairs’ communication of these same thoughts helped me quickly settle in. I’ve found it effective to have a quick conversation at the start of the session to see how your pair is feeling and what role they prefer.
The most common advice I’ve seen in reading through others’ feedback is to constantly communicate ALL your thoughts. It’s best to err on the side of over-sharing to ensure everyone is on the same page. In one early piece of feedback I’ve received, I was kindly reminded to constantly communicate as we worked though the code. This gentle nudge of feedback led me to remind myself to always check in with my pair to make sure we’re both on the right track. I’m grateful for each bit of feedback, because it can can gradually help me become a better programmer and team mate.
Conversely, the downside of pair programming is that some things are better accomplished alone. People work differently and some need the privacy to work through problems without interruption. Like any great creative endeavor, solitude helps people formulate their plans, be productive, and have the freedom to experiment. I believe a good balance of solo and paired programming is ideal. On my own, I’ve learned and advanced in ways I don’t think I could have with a pair. The same goes for working with someone else. Both strategies are very helpful at different times.
I’m glad that DBC does a great job encouraging pairing and setting up ways for pairs to build mutual respect and understanding through feedback. I’m excited to keep developing these skills so I can use them when I get to the DBC on-site portion, which includes a lot of pairing. I’m even more excited to use them in a professional setting when I become a member of an engineering team!
