Goals of Pair Programming
If you’re reading this, there’s a strong possibility you’ve taken a CS course. It’s also likely you’ve heard of, or even participated in, some peer programming. Pair programming — otherwise referred to as peer programming — is an Agile development methodology that celebrates collaborative programming with a simple dynamic: two programmers, one keyboard.
The programming pair contains a Driver and an Observer. The Driver sits at the keyboard, focusing on the task or code at hand. This frees the Observer to consider quality, conformity and scope.
In a college scenario, this would suggest ownership of half a project but in software development the whole is greater than the sum of its parts. Pair programming tackles a number of critical goals: producing fewer bugs, creating more elegant solutions, and promoting growth.
Let’s talk about each of these in more detail.
Stability
It’s easy to get in the zone and find yourself 300 lines in on your project, only to realize you mixed up some variable names, left out a semicolon, or made other trivial mistakes. A second set of eyes is a great safety net to catch any missteps. Though the issues may be farther reaching than you originally thought, having an observer dedicated to thinking about the big picture is hugely helpful.
Pair programming is less useful for vetting code in test-driven development environments. Many of the bugs an observer would catch are trivial, and typically flagged by tests.
Stability is just a small cog in a much larger machine dominated by processes with far more impact. This point is illustrated well in this article by Kevin Burke.
Elegance
Every programmer brings different perspective and knowledge to the table. Two people melding minds on the same challenge often leads to the discovery of more creative, elegant and simple solutions to problems that neither programmer would necessarily arrive at on their own. This can positively impact application performance and reduce maintenance in the long term, which will save you money.
This elegance differs from code styling, which we employ here at Ontraport, in that code style is a set of enforced rules used to maintain consistent, readable code. For example, on our Front End team, we leverage the BEM code style for our CSS. Any team or programmer looking to improve their code readability should consider implementing code styling.
Growth
Pair programming is a key element of integrating new engineers with our team. To quickly and seamlessly introduce them to the application, experienced team members take time to both guide and drive new engineers through actual, consequential development tasks. This development-driven exchange of knowledge incubates growth, confidence, and empowers the programmers in unique ways.
When I joined the Ontraport team I worked very closely with another newly hired engineer. We were shown the ropes, given a task to solve, and unleashed upon the code. In a few days, we had solved our first bug ticket. Along the way we exchanged technical knowledge, programming practices, offered unique perspectives, and became fast friends!
In more general situations, this exchange of knowledge can also be observed during pair programming. No matter the experience level of each programmer, there is almost always something to be learned. Pair programming can be humbling, but it also cultivates camaraderie.
Further Thoughts
Parallel to the primary goals of pair programming are a number of ancillary benefits worth mentioning.
Team Morale
As engineers, we tend to isolate ourselves in our routines. It’s habit to go into the office, pop in some earbuds, and get into the “zone” or be “wired-in.” Before you know it, it’s the end of the day and a room full of engineers have gone an entire day without uttering a word to one another. At times, this is an absolute necessity, but it’s also valuable to the organization for programmers to mingle.
Allowing programmers to empathize with one another’s work and challenges enables them to approach giving and receiving criticism, advice and pointers from each other in a more positive way. In turn, team morale improves and a positive foundation is built. We don’t have to be friends; that isn’t the point, but it’s important that we know how to work together cohesively and productively.
Point of Failure
Another important benefit of pair programming is the extra layer of insulation it provides against single points of failure. When working on a team, one person may be delegated a complicated task to which they produce an elaborate solution. The problem with that is the fallout if one programmer suddenly departs. How much time will have to be spent combing through the code, trying to understand how it worked….why this, instead of this? Pair programming provides a safety net, ensuring that the inner-workings of the code are intimately known by at least one other person.
If you’ve made it this far, maybe you’re thinking about giving this whole pair programming thing a try in your organization. I encourage you to take the plunge, but with caution. As with many tried-and-true methods, pair programming isn’t a one-size-fits-all solution. Take the time to explore the impact and the best way to introduce the method into your workflow. Our team recommends giving it an hour a day to get your toes wet. If that goes smoothly and proves valuable, create a more strategic schedule and process that makes sense for your organization and its needs.
Best of luck!
