The Power of Pairs

Rate this content
Bookmark

Engineering team often face difficult challenges with constrained resources. If the job requires 1 engineer, we put one on the job. If it requires 2, we split topics into actionable chunks and assign them to individuals.


But there are several benefits to do things in pairs: It helps to catch errors and bugs, it allows for better communication and collaboration between team members and it can also lead to more efficient and higher-quality code, as engineers can challenge their peer's assumptions and suggest alternative approaches.

Octave Raimbault
Octave Raimbault
21 min
09 Mar, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Pair programming is a collaborative software development technique where two developers work together at one workstation. It offers benefits such as easier code maintenance, faster code reviews, and reduced likelihood of bugs. Implementing pair programming involves finding compatible partners, setting goals, and establishing clear communication protocols. To address challenges, provide training and support, involve team members in decision-making, and carefully select partners. Pair programming can help achieve goals like collaboration, knowledge growth, code stability, and maintenance.

Available in Español

1. Introduction to Pair Programming

Short description:

Hello, and welcome to the Power of Pairs, a talk about 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, who participate in pair programming, are equal partners, each with its own responsibilities.

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.

2. Benefits and Challenges of Pair Programming

Short description:

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.

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.

3. Benefits of Pair Programming

Short description:

Pair programming is a practice that pays off when you consider the costs that can be avoided or reduced. It allows for faster code reviews, quicker testing, and reduces the likelihood of bugs. It also increases team familiarity with the code base and reduces maintenance and future development times.

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.

4. Implementing and Improving Pair Programming

Short description:

Pair programming is a great way to tackle complex tasks, share knowledge, onboard new team members, and foster collaboration. To implement it, find the right match, prepare necessary tools, set goals and expectations, plan the session, rotate roles, and establish clear communication protocols.

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.

5. Effective Pair Programming

Short description:

Teams should establish clear protocols for communication and a common language. Avoid distractions and take regular breaks to prevent burnout. Stay positive and open-minded to encourage collaboration.

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.

6. Challenges and Implementation of Pair Programming

Short description:

Let's address some common challenges of pair programming: finding compatible partners, resistance to change, skill and experience, and engineering structure. To address these challenges, provide training and support, involve team members in decision-making, carefully select partners, and plan pair programming sessions carefully. Pair programming is just a tool, but if chosen, introduce it gradually, seek feedback, and reassess regularly. It can help achieve goals like team collaboration, knowledge growth, code stability, and maintenance.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Impact: Growing as an Engineer
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
On Becoming a Tech Lead
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Top Content
Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
Top Content
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
Fighting Technical Debt With Continuous Refactoring
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
Effective Communication for Engineers
TechLead Conference 2023TechLead Conference 2023
36 min
Effective Communication for Engineers
Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.

Workshops on related topic

How To Design A Sustainable Freelance/Contracting Career
Node Congress 2022Node Congress 2022
39 min
How To Design A Sustainable Freelance/Contracting Career
WorkshopFree
Shane Ketterman
Alexander Weekes
2 authors
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn the tricks of the trade from the industry’s most experienced freelancers.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Designing A Sustainable Freelance Career
React Advanced Conference 2021React Advanced Conference 2021
145 min
Designing A Sustainable Freelance Career
WorkshopFree
Alexander Weekes
Rodrigo Donini
2 authors
Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work.>> Submit your interest on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist <<

Freelancing is no longer an unstable career choice.

This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Table of contents

Module 1: Dispelling common myths about freelancing
Module 2: What does freelancing look like in 2021 and beyond
Module 3: Freelancing choices and what to look for (and what to avoid)
Module 4: Benefits of freelancing from a freelancer + case study
BREAK
Module 6: How to get started freelancing (experience, resume, preparation)
Module 7: Common paths to full-time freelancing
Module 8: Essentials: setting your rate and getting work
Module 9: Next steps: networking with peers, upskilling, changing the world
Module 10: Freelancer AMA