Pair programming is an agile technique that comes with many benefits. During a pair programming session, two brains are employed instead of one on a same coding problem. As a social methodology, it forces the most introverts of us, developers, to convey our mind out loud and articulate it on the go. The underlying purposes are many, from sharing technical and domain knowledge with your team to improve overall code quality.
Let’s get each benefit of pair programming in review.
The ultimate benefit of pair programming is without contest its ability to spread knowledge among team members.
When you are solo programming, you make micro decisions on how to effectively address problems. You take into account what you know of the code base or think about particular conflicts that may arise now or in the future. What happens next is another developer in the team builds a related component to yours and gets a hard time understanding why you made those decisions, because they don’t see immediately the logic or the reasons behind.
If you recently pushed the code, you can tackle situation in a few minutes over Slack, Teams or any other messaging tools. Conversely, an old piece of code requires you to dig in tickets and commits to recall why you chose that path. You thus have to go through context switches and you might experience difficulty to communicate clearly or even get flustered as you feel a sense of urgency. It gets even worst when you’re on PTO or just off sick and still check your notifications just to be told that “what you’ve coded the other day will not work”.
Without a strong culture based on communication and documentation, solo programming can lead teams to silos. Silos slow down velocity and reinforce the competitive environment within the team. Pair programming enables teams to naturally share information and spread knowledge among members. With sessions focused on communication and shared goals, it benefits teams as they can achieve collective code ownership and highly decrease the bus factor.
Another advantage of pair programming lies in how it enables you to share best practices with your team. We all have our own approach when it comes to coding. Our brains don’t all address problems the same way and we actually often use strategies that have produced results before in the first place.
After spending years coding all day long, we acquire some automatisms and coding gets repetitive. At this stage, the best you can do for your team is to openly share those automatisms. This does not only let younger developers ramp up faster and encourage them to build their own automatisms on the long run, but you also ensure you and your team are all on the same page.
Therefore, sharing best practices through pair programming makes a lot of sense as you’re able to demonstrate the value of any automatisms you developed on situations that require so. Practicing on real and concrete cases is the best way to instill knowledge in people. You can’t expect juniors to fully ramp up by just sharing them your best coding practices playbook. You can’t expect seniors to write good tickets, systematically elaborate on issues they encountered or test their code effectively before moving tickets to the next stage by just telling them to do so. You need to actively communicate and show by example. Pair programming is an handy tool for that purpose.
Pair programming comes with a set of best practices including who does what at any given time. Traditionally, the pair roles are divided between the driver and the navigator. The former is responsible for achieving the small objectives or steps, one by one. The latter reflects on the big picture and gives the next directions. As the navigator, you can see way beyond what the driver is currently coding. You make use of your third eye power to detect obstacles and conflicts with the other pieces of code before they happen. You then discuss together what the best approach or workaround could be.
As a solo programmer, you risk missing huge potential issues you’re not even expecting, especially when you don’t have the big picture of the code base in mind. This is generally where code review comes into play. After you declare you’re done with the task, another developer looks at your code and raise warnings by kind of redlining your code and writing comments, much like how legal team review agreements.
The reviewer is ultimately responsible for letting your code pass to the next stage on your Scrum board, for example QA, or go straight into production. The problem with code review is that no reviewer is infallible. Reviewing someone else code requires discipline, context switching and spending a lot of time reflecting on potential issues. It requires a lot of efforts and deep focus. Thus, most often than not, reviewers put way too much trust into the author’s code, leading to defects not being caught before landing into production.
Pair programming is considered as a replacement process for code review. This is particularly the case when it includes at least one experienced participant in the pair. Pair programming prevents context switches that code review implies. Pull or merge requests stop being passed back-and-forth again and again as both developers involved in the pair share the same context and have the opportunity to eliminate potential defects before they are introduced into production.
Technical debt is a constant uphill battle for any development teams. To deal with it, you have to get disciplined as a team and embrace a culture of periodical reviews. If you don’t, sooner or later your code base will internally implose and any changes will require a lot of efforts. That’s not an easy task when your team is tight on deadlines.
Fortunately, pair programming inherently helps developers discuss and challenge solutions as they emerge, allowing to write less lines of code but with a way better quality overall. This is what NASA engineers concluded in 2001 after they did an experiment, using Emacs and Ruby, to see how pair programming improved their productivity and helped them increase their business value delivery. They compared what produced a solo developer and a pair programming team. After 6 weeks, the solo developer had written 2144 lines of code with no testing. After 3 weeks, the pair programming team built the same functionality with 866 lines of code, including 463 lines of test. The author attributed the reduction in lines of code to agressive refactoring and continuous code review inherent to pair programming.
All in all, combining two heads through pair programming lets you see beyond the problem at hand. It allows you to predict the future and come up with better and sustainable solutions.
All of us developers are faced soon or later with a recalcitrant piece of code. No matter how many times we re-read and alter it, it simply refuses to work as we intended it to do. To palliate this situation, a technique known as rubber duck debugging was introduced and popularized in the book The Pragmatic Programmer, published in 1999. The story in the book, whose technique’s name is taken from, is about a programmer who purposefully describes each line of their non-working code to a rubber duck. By articulating every steps of their solution out loud and checking the results, they tend to find the mismatch between what they expected and what actually implemented. Finally, the source of the issue becomes clear.
This technique is being taught in computer science courses and can be used with any inanimate objects or even pets, so you don’t have to importune other developers. With pair programming, the whole pair is already involved with the reasoning behind the code. It forces you to convey your mind out loud and explain each step you go through. Therefore, using pair programming in such tough situations that require a second pair of eyes can highly benefit your team.
An underestimated benefit of pair programming is how it lets you onboard new team members blazing fast. Here’s the deal, your company has just hired a new software engineer and you’ve been assigned as their onboarding buddy to support them while they go through your day-to-day processes, explore your code base and familiarize with your tools.
By doing frequent pair programming sessions with them straight from the beginning, you’re able to inculcate a clear vision in them on how components of your project interconnect. It also enables you to elaborate on their specificities instead of letting them dig through the whole code base all alone. Additionally, it’s an opportunity for the newcomer to quickly familiarize with their new environment, find their place within the team and get a glimpse of the company’s culture. Pair programming drastically lowers the time required before new team members are fully ramped up.
But it does not only benefit the developer being onboarded. As the onboarding buddy, you also get a chance to discover any missing internal documentation as you unroll your explanations and give directions. This happens all the time. Eventually, pair programming lets you ensure the just hired software engineer is really a good fit to the team by defining short term goals and measuring success on the go.
Staying focus all the time can be hard when you’re solo programming. It's especially true when you are confronted with a complex problem. As a curious human, with such qualification highly implied by the nature of your job, you might tend to explore different routes to solve a problem. You know, just to satisfy that itching curiosity. Only for you to select all the code you wrote a few hours later, hit delete and revert back to a simple solution.
Pair programming forces you to stay focus together and prevents you from getting stuck on minor details for too long. As a pair, you feel accountable to each other. In a similar way and when employed conscientiously, pair programming helps you stay away from email notifications, phone messages and other distractions. The counterpart to that deep focus and constant talking is that you feel more exhausted at the end of the day than when you’re solo programming. Just make sure you take breaks regularly.
The last benefit is inherent to the nature of pair programming and the social dynamics it implies. A development team like many others is subject to competition among members. Competition can be healthy as it enables developers to set personal objectives and excel in their work.
However, the right balance must be found between teamwork and competition to ensure team cohesion and prevent demotivation or even turnover. For example, software engineers who work individually on the same code base might develop a toxic behavior when they stumble upon an implementation of a solution that diverges from what they would have done, convinced they know better. Some programmers even aspire to be a go-to person a team can’t live without.
Pair programming, when done extensively and with frequent rotations within a team, lets you put all the developers on the same page. By actively discussing and challenging solutions to problems with their team, developers become accountable for the whole code base.
Furthermore, pair programming makes you show your true self, not who you aspire to be. You have to remove your shield and expose your vulnerability to get the most out of any pair programming sessions. But it’s ok, the promise is a healthier environment with empathetic colleagues who care about the team and share the same goal, succeeding together.
As we’ve just discussed, pair programming comes with many benefits. When employed the right way, with patience and a determined will to make it works, pair programming can deeply transform how developer teams communicate and share knowledge internally. We, developers, are curious live beings by nature. Don’t let evaporate what you learned along your journey. Schedule some time with another developer in your team to tackle a complex problem together that they have been through for a long time. Take a sit next to them or pair remotely using Drovio.
Pairing is sharing, pairing is caring, pair widely.
Create your free account and start collaborating right away with your team on all your apps. Should you have any questions about our offers, be sure to contact us.
