In the strictest sense, pair programming involves two developers sitting side by side, each taking approximately fifteen-minute shifts driving the code, and watching code being written. Broken down to this basic definition, pair programming might sound like a big waste of time and money for everyone concerned, with clients having to pay two programmers to do the job of one.
In reality, the practice is much more dynamic, and almost always leads to the client getting faster results with fewer bugs, wrapped up in a superior product.
At its core, pair programming is about having someone validate your thought process, and provide their background and expertise while learning something themselves. It’s mutually beneficial to see how someone else works and to add your skill set to it, resulting in a leveling-up of both developers.
Having an extra set of eyes to spot typos, or point out a missing semi-colon (something that can set a programmer back hours searching for what they think is a more complex problem) can save huge amounts of time and headaches later on.
But it’s not just about catching bugs along the way. Someone beside you asking “Why are you doing it that way?” can spark conversation and result in finding a more efficient way to solve a problem.
Like the rubber duck practice some developers employ where they explain their code out loud to a physical rubber ducky (the idea being that by explaining your code, even to an inanimate object, you’re more likely to see errors in the code or its logic), pair programming is like having an interactive rubber duck. Having to explain your thinking to someone who asks “Why?”, keeps both developers in an inquisitive frame of mind, rather than just being driven by routine and old habits.
Not just purely for coding, pair programming is also an extremely effective tool for engineering a product. Working together to solve a complex problem and plan out the logic of the code in advance, simplifies the task, and sends both developers off in the same direction with an understanding of what the other one is doing, even while they’re working apart.
It’s also great for onboarding people, not just into the company, but into a project. A developer who’s new to a project and doesn’t have the context can pair for even a single day and get up to speed much more quickly, maximizing the work time before a project’s due date.
Pair programming also improves understanding of how each team player works, leading to better communication and trust across the team; something that’s essential when developers aren’t always in the same physical space. It also keeps developers focused, not wanting to waste the time of the person paired with them.
To a client, pair programming can seem like a waste of their money, and certainly the more ideological approach of consistently having programmers code side by side can be a harder sell.
That’s why we see pair programming as an organic process where at any time a developer can reach out to another and prove that two heads truly are better than one. As in any industry, setbacks occur in software, and clients often balk at hearing “two developers worked on a single problem together for half a day.” However, it’s better than the alternative.
Imagine Developer A gets stuck and doesn’t ask Developer B to come over, resulting in a missed deadline. This puts a hold on the next task that Developer A was supposed to work on, and another deadline passes. Finally, they ask Developer B to help out, possibly resulting in Developer B also missing their deadline. Now they’re in damage control mode, but often it’s way too late.
Instead, if Developer A is quick to say “stop what you’re doing and come over here,” the pair together can probably solve A’s and B’s tasks much faster, completing both before their due dates. When clients hear that they’ve been saved potentially weeks’ worth of delays, they instantly see the benefits of pair programming.
We’ve seen the benefits time and time again in the cross-pollination of skill sets and experiences across the company, and in the high-caliber results for the client. We support it in our workplace because we know it works. That’s why pair programming is at the core of what we do.
Not sure what your expectations are? Need some help establishing good communication and collaboration practices? Don’t worry – a great development team can help you figure it out and stay organized through each phase. Just ask!