The Power of Pairs

Hello, and welcome to the Power of Pairs, a talk about pair programming. My name is Octave and I'm a software engineer at Datadog. I've been a software engineer for the last eight years and this presentation is based on both my personal experience as well as some research papers and articles available online.

Let's start with a quick introduction for those who are not yet familiar with pair programming. Pair programming is a collaborative software development technique where two developers work together at one workstation sharing a keyboard and a mouse. The two developers work together to complete a task such as implementing a feature, fixing a bug, or writing tests. One developer, the driver, is responsible for writing the code while the other developer, the navigator, reviews the code, provides feedback, and suggests improvements. The two developers, who participate in pair programming, are equal partners, each with its own responsibilities. It is much like the team of a rally car, with the driver maneuvering the car very precisely, while its partner is focusing on the map, and giving the driver a heads-up about turns and other road specificities. The two roles complement each other and are equally important.

Let's now have a look at some compelling arguments as to why you might be interested in pair programming in your team habits, and also as counter-arguments. There are many upsides to pair programming and they will vary depending on the specificities of your organization. Nevertheless, here are some of the most common and sought-after benefits of pair programming.

As code is thoroughly reviewed and built combining the knowledge of two engineers, it is likely to be easier to maintain and less likely to cause errors and bugs. As developers spend more time sharing thoughts and practices, as well as witnessing their teammates' developing practices, they provide growth opportunities for one another. It can have a very positive impact on morale, as teammates spend more time together and bond over professional activities. It may involve one individual intervening on a part of the product they are not responsible about, which gives them an opportunity to ask questions and learn about it. Finally, when taking a holistic look at productivity, pair programming will frequently have a positive impact, and we will talk again about that later in the presentation.

There are also some downsides and challenges. They can have an important impact on the outcome of your pair programming sessions. The first and by far the most frequent argument is that pair programming is not cost-efficient. A study from two researchers at Microsoft says that there was considerable, quote, skepticism that having two people working on one task is a good use of resources. And later on, that manager buy-in was also challenging, with one of the managers stating, quote, if I have a choice, I can employ one star programmer instead of two programmers who need to code in pair. This is something we'll talk about again later in this presentation, as it can be arguable and there are different figures to look at. Another issue is finding partners who work well together. Team members may have different working styles, preferences, personalities and cultures that can make it difficult to find a compatible partner. Resistance to change is another one. Some developers may resist the change to pair programming and prefer to work alone. This can be a significant challenge, especially if team members are not used to collaborate closely with others. For example, they may feel like they are being watched over or micromanaged when they are in the driver seat. Finally, effective communication is crucial for pair programming, and so it can also be a challenge, especially if team members have different communication styles or preferences. Personally, I've had the experience with multicultural teams where it sometimes increases the risk of not properly communicating, as you may not be sensitive to the same words and meanings and attitudes as the other party. These challenges are definitely valid arguments, and later in this talk, we'll mention ways to address and try to mitigate their impact.

To add some context and practical figures, here are some of the feedbacks gathered in a study done at Microsoft in 2007. These are the top 5 most brought up arguments in favor and against pair programming, with a score representing how often these arguments were brought up by the people in the study. This is of course a single study, and others may be in different rankings and items, but I think this one gives you a pretty accurate representation of how developers feel about pair programming overall. I want to take some time and address the cost argument. As we saw that it is by far the biggest worry. Let's first start by saying that it would be most often wrong to think that it doubles the cost. This is because you very often do not spend a full development cycle in a pair programming situation.

A study from the University of Utah showed that the overall increase in development time was around 15% on the dataset that they had. Moreover, just like investing in refactoring can be beneficial for the long-term benefits of the organization and the codebase, pair programming is a practice that pays off when you look at all the costs that can be avoided or reduced. For example, the additional time invested in development will allow for faster code reviews, since the reviewer will be more familiar with the parts that are being changed. Testing the changes is also quicker, as developers are more aware of the intent behind the code, and can easily test the different scenarios impacted by the modifications. Bugs are also less likely to arise, since the work has been cross examined very thoroughly, and had two different mindsets applied to it. Finally, this practice increases the team familiarity with a broader scope of the code base and the product. Consequently, maintenance and future development times are reduced. When you take all those costs and add them up, and compare them to the initial investment that you had on the development part, they can either balance the initial cost or completely reimburse it and even make you gain time. This makes pair programming an investment that, just like investing in technical depth, will benefit the team over time. I hope this part about why you may want to give a try to pair programming was convincing enough.

Let's now go over how you can implement or improve pair programming in your organization. First of all, we should look at what are good opportunities to apply programming and when to use it. Pair programming can be a great way to tackle complex tasks or problems that require a lot of brainpower. By working in pairs, team members can bounce ideas of each other, brainstorm solutions, and catch mistakes before they become larger problems. By pairing team members with different areas of expertise, team members can learn and develop new skills, becoming more well-rounded developers.

Pair programming can be an effective way to share knowledge and skills among team members, and it's not just for new developers or junior programmers. In fact, experienced developers can also benefit from pair programming, as it can provide a fresh perspective on a problem and lead to new insights and solutions. Pair programming is also a great way to onboard new team members. By pairing team members with more experienced members, new team members can learn the codebase, the development practices of the workplace, and the workflows while working side by side with one of their new teammates. Finally, pair programming can simply be used as a very good excuse to spend more time with co-workers. Spending more time together and investing that time toward a common goal helps teams build camaraderie, improve communication, and foster a culture of collaboration and learning.

Here are a couple of steps to bootstrap your first pair programming sessions. First, you need to find the right match for the topic you'll be working on. Do it based on why you chose to do a pair programming session, for which we showed ideas in the previous slide. For example, if your opportunity for pair programming is to onboard a new team member, you may want to pick a partner with a good product understanding and a knowledge of a broader part of the code base. If you decided to work on a complex task, on the other hand, you should probably choose people with specialized skills and in-depth understanding of the part of the product you'll be working on. Next, prepare the necessary tools to get the job done. Remote teams may benefit from a conference tool such as Zoom, and from an advanced IDE with collaboration features such as Visual Studio Code and its Live Share feature. For on-site teams, you will need a quiet space, such as a conference room, and you should leverage simple tools, like a drawing board. Once you have all this, clearly set the goals and expectations. Should you have a valid pull request by the end of the session? Or are you in an earlier phase of development where you just want to get the groundwork done and plan? What are both parties expecting to learn from the session? You should probably find key success metrics to ensure that you will not lose time or be diverging during the session. Finally, plan the session ahead of time and limit it to a reasonable amount of time. A session should usually last 30 to 60 minutes. You can use the Pomodoro technique to help you set the appropriate amount of time and be reminded about regular breaks. To make the most of pair programming during the session, it is important to follow some best practices. First, rotate roles regularly. To ensure that both team members have an opportunity to contribute and learn, it is important to rotate roles on a frequent basis. This allows each team member to experience different aspects of the process such as writing the code or giving direction, and it also helps to ensure that both team members stay engaged and avoid getting stuck. Establish clear communication protocols. Clear and effective communication is essential for the success of pair programming.

Teams should establish clear protocols for communication, including things like how to ask for help, how to offer feedback, and how to handle disagreements. It is also important to establish a common language and terminology to ensure that both team members understand each other.

Avoid distractions. Turn off notifications and apps that may require your attention during the meeting. Make sure that you are not expected to respond quickly to anything, such as an issue in production. The navigator role here is also to make sure that they don't get sidetracked by something in the code or the product, and stay on the road. If you happen to discover something that is not related to the target during the meeting, take a note and go back to it after the session.

Take regular breaks. Pair programming can be intense, and it's important to take regular breaks to avoid burnout. Teams should take short breaks every hour or so to rest, stretch, and recharge. This can help improve focus and productivity and prevent fatigue or boredom from setting in.

Finally, stay positive and open minded. Pair programming requires a positive and open minded attitude. Teams should encourage each other to stay positive and avoid negative criticism or blame. Instead, focus on finding solutions together and learning from mistakes. A positive and supportive attitude can help to build trust and encourage collaboration, leading to better results. And of course, this doesn't limit to only the pair programming session.

Let's address now some common challenges of pair programming and how they can be addressed. Finding compatible partners. One of the biggest challenges of pair programming is finding people who work well together. Team members may have different working styles, preferences or personalities that can make it difficult to find a compatible partner. To address this challenge, it is important to provide training and support for teams to improve their pair programming skills and to help them learn to work effectively with others. It can also be helpful to encourage new team members to try working with different partners to find a good fit.

Resistance to change Some developers may resist the pair programming aspect and prefer to work alone. This can be a significant challenge, especially in teams where members are not used to collaborating closely with others. To address this challenge, it's important to involve team members in the decision-making process and to provide training and support to help them become more comfortable with the technique. It can be helpful to start with short, focused sessions, and gradually increase the amount of time spent in pair programming, once you validate the practice and notice that it is well received by the team.

Skill and experience is also a challenge. This challenge is about ensuring that both team members have the necessary skills and experience to work effectively with the other. This can be addressed by carefully selecting partners with complementary skills, as we've shown previously. And by providing training and support to help team members develop the necessary skills. Finally, engineering structure. It is common in an engineering or product department to break teams down into task forces dedicated to specific product investment. And this is a very valid practice to improve productivity and help people focus on a few tasks. But from a personal experience, this also creates silos in which you might not have many pairing opportunities. As often, you only have one or two engineers in your specialty working on the same topic. This means that you will need to seek people working on other topics and initiatives to pair program. In order to do it without putting their project at risk, you need to plan and time-box very carefully. You also need to avoid doing that during tough times, like situations where they have a very strong deadline. You may also offer to do a session of pair programming on their initiative afterward. This will put things in balance and in the end, both developers will be more aware of both topics.

Before I leave you with the next speakers, I'd like to share some closing thoughts. Pair programming, in the end, is just a tool. You may choose to use it or not. If you choose not to, you'll have to use other tools to achieve the same goals that you set for your team and organization, such as building a strong team collaboration, growing knowledge, and ensuring the code stability and maintenance. However, if you do choose to use it, you need to introduce it just like you would any other tool. You'll first need to clearly communicate with your team about what it may bring, and seek their buy-in. You'll then need to gradually implement it in a way that works for them, and for your organization. You'll need to regularly seek feedbacks and reassess along the way. And if you're successful, then your team will have one more tool to its belt that it can use to sheet better code and to work better together. This talk was about helping you take that decision with the belief that there are many scenarios in which you should give it a shot. However, I also encourage you to do your own research and read some papers available online to prepare for the task ahead. I hope you liked this talk. Thank you for listening to it.