The Benefits of Pair Programming

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.

Spread knowledge

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.

Share best practices

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.

Introduce less defects

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.

Refactor on the go

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.

A live rubber duck

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.

Lightning fast onboarding

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.

Eliminate distractions

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.

Build up team cohesion

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.

Remote Pair Programming: The Specificities

Using remote pair programming (also known as distributed development) allows developers to collaborate in real time and on the same codebase regardless of their location or physical distance from each other. Remote pair programming provides many benefits over more traditional ways of working, such as reduced overhead costs, improved code quality, better coordination and communication between developers, improved employee satisfaction and retention, and more flexible scheduling options. But remote pair programming can also present some challenges that you’ll need to be aware of if you want your team to reap the benefits without encountering any problems...

What is Remote Pair Programming?

In short, remote pair programming is having two programmers collaborate in real time through one computer. One person writes code while another reads it, giving feedback and tips on how to improve code. Remote pair programming helps you get more work done because it’s less isolating than coding alone. But before we can talk about remote pair programming, let’s first talk about regular pair programming. (Regular pair programming is where two programmers are sitting side-by-side working together to solve a problem.) Regular pairing has many benefits: both people are typing away at their own computers; they’re reviewing each other’s work; they can jump on any problems that pop up; and they can bounce ideas off of each other constantly. There are drawbacks as well—they aren’t necessarily saving time because they have to run back and forth for questions or help; not everyone works best when paired up with someone else all day; some companies don't think its cost effective for every programmer to be paired; etc... If you want to learn more about why pairing is beneficial, check out our article on reasons why pair programming rocks! 

What are the Benefits?

The biggest advantage of remote pair programming is that it greatly expands a team’s flexibility when considering where people work. If an employee has a family emergency, or if they simply want to move closer to relatives, there’s no need for them to relocate; most companies provide laptops and a good internet connection, so employees can stay at home and keep working remotely. Remote workers also typically cost less than in-office employees; they don’t have an office or parking space to pay for. Additionally, many find that they prefer telecommuting—it gives their family a break from interruption and allows them to focus on getting their job done well. There are some disadvantages to telecommuting as well: company culture can be lost, especially if your company relies on day-to-day interactions between coworkers. A pair programming tool like Drovio solves some of these problems! Despite these potential issues, more and more companies are going remote because it allows them to expand without having physical limits—there is no longer a requirement for everyone's office/workplace being co-located.

How Does it Work?

The two developers are connected through a pair programming tool (such as Drovio, of course!). The developers can see each other’s screens, get their own mouse cursor on it, and use voice chat to talk about and resolve issues in real time. This process is very effective, because it allows for quick feedback loops and improves overall programming efficiency. Depending on team members' personalities, one developer might be more comfortable with pair programming while another prefers solo work. By giving both types of personalities an opportunity to try remote pair programming, you will likely find that your team likes using remote pairing or they don't. You may even find that after getting a taste of pairing remotely, they want it all of the time! If so, make sure you have at least 2 monitors per person working in pairs or set up a second screen available specifically for remote pairing. 

Who Should Use It?

It doesn’t matter if you’re in an office or working from home, remote pair programming has a number of benefits and can be very useful if you have a developer who doesn’t work with anyone nearby. It also helps facilitate communication between colleagues when there are time zones between them. This technique is often used when developing complex software like operating systems or large-scale applications that require constant attention to detail. Remote pair programming allows one engineer to lead while another follows along; it encourages transparency and rapid feedback so mistakes can be caught quickly and fixed easily. Since errors are noticed as they happen, bugs aren’t allowed to hide until released into production at which point they could cause widespread issues for your clients or company.

Things to Look Out For

In a remote environment, it's easier to miss some of those subtle cues that you'd normally get from being in a face-to-face meeting. For example, when someone asks you to repeat yourself or doesn't answer your question directly; these things usually give away a bit more about their thoughts. It is important to be aware of these little clues and adjust your attitude towards communicating with them accordingly. For example, if they ask you to repeat yourself, it might mean that you are talking too fast or not speaking clearly enough; they might not be catching all of what you're saying so try slowing down. If they take a long time answering your question or avoid answering altogether, it may be because they feel like you didn't really understand their point - try asking for clarification on what you don't understand. All these micro adjustments will start to build over time as you work with people remotely and make sure that everyone is feeling more comfortable working together remotely every day. The bottom line: no matter how well you know each other, communication can always be improved - just pay attention!

Tips For Success

If you’re just starting out with remote pair programming, there are a few things you should know. First of all, remote pair programming can be incredibly rewarding; however, it does take some time to get used to. Here are some tips for successful remote pairing: Face-to-face conversations about your screen and code require patience, understanding and mutual respect. It is particularly important to agree on when you both need to talk or if it's okay not to say anything at all. Make sure you can trust your partner by seeing them in action during short pairing sessions before trying longer ones over a distributed network. Remember that working remotely means people need more time, which makes effective communication even more critical than usual. Don't expect miracles from yourself; as Albert Einstein said If we knew what we were doing, it wouldn't be called research. Also mind your posture: sitting for too long causes back pain and neck strain so try getting up regularly. 

Setup of a Pair Programming Room

Pair programming rooms can come in all shapes and sizes, from dimly lit backrooms to bright and airy conference rooms with wall-to-wall windows. However, all pair programming rooms should include several important features to help everyone get the most out of their experience while working together. In this blog post, we’ll look at the five most important features every pair programming room should have in order to maximize productivity and encourage collaboration and creativity in teams of programmers looking to do some great work together.

Blocked Off Room

Sometimes, room layout can get in your way of being productive while you work. This is especially true for programmers who need to concentrate on their work. You’ll want to avoid rooms with excessive distractions, including music and other people working near you. Instead, you should set up shop in a private office or quiet room where nobody will bother you. Blocked off rooms are excellent for pair programming since it keeps your focus on each task at hand. If you end up pairing with someone who tends to chit-chat during development, they won’t be able to distract you while you code. Chances are you’ll find yourself more focused when working out of blocked-off offices.

Natural Light

Working by natural light helps create a better work-life balance. Spending all day inside of an office can make you feel like you’re working constantly—leaving less time for socializing and exercise. Studies show that having access to natural light helps improve focus, mood, and productivity; why would you not want to take advantage of it? Additionally, keep in mind that sitting too close to your monitor could be detrimental to your health; opt for moving your chair farther away from your desk at least once an hour. 

Natural light
Let the sunshine in!

Whiteboard Wall

A whiteboard wall is a must in any pair programming room. Whiteboards are always available when you need them and there’s no need to rearrange your furniture if you don’t have space in your office. As with every piece of equipment in a pair programming space, choose a whiteboard that’s big enough to work on with another programmer—anything smaller than six feet by three feet is just asking for trouble. If possible, get one or more dry-erase electronic writing pads that will let multiple people simultaneously edit their own copy of what someone has already written on a board. 

A Biiiiig whiteboard

Lots of Desks

The best pair programming rooms should be set up with lots of desks, allowing pairs to easily form and disband. This is because pair programming works best when programmers switch off often—and having a large number of desks ensures that people who want to switch partners can do so quickly. Also, by keeping a large number of desks free at all times, you prevent pairs from getting attached to each other and makes it easier for anyone in your office to start working on a project together. A lot of natural conversation also happens between pairs sitting at adjacent tables.

Projector / Large Monitor

A large-screen projector or monitor is a must for any pair programming session. It allows all team members to see what’s happening on each others' screens, facilitating better communication. Any projector will do, but you might want to keep in mind size of your office and distance from your work station. You may also want to consider things like audio output, where you'll be storing your laptop, and whether or not you need additional peripherals. (Projectors typically don't come with built-in microphones.)

projector
However, we DO NOT recommend that kind of projector

We hope you enjoyed our article about the best pair programming room, setup and material. With this knowledge, we know you can make the most of your company's pair programming time and collaborate with ease during your next pair programming session. So what are you waiting for?

Pair Programming Partner Picking Principles

Pair programming is an excellent technique that can help you to develop your skills and help you learn from another person's perspective on software development. However, picking the right partner can be difficult, and this guide will help you pick the right person who will complement your working style and bring out the best in you as a developer. By following these pairing partner picking principles, you’ll have a much more productive experience.

Expert-Expert pairing

You will want to find someone who is either better than you or at least at your level. When you choose an expert as a pairing partner, be prepared to take on more responsibility for writing code. The best way to balance out expertise levels is by partnering with someone who is slightly below your level. They’ll ask great questions that force you to think about things that might not have otherwise occurred to you; but they won’t be able do everything for you.

Expert-Novice pairing

The most common pairing type is expert-novice, where one person is more experienced than another. Expert-novice pairings are most useful when you have high variability in skill level or knowledge among your team. For example, if you have a team of five developers working on different parts of a single product, it can be very useful to have one developer who knows each part well and one developer who is just learning that part. The expert partner can help by explaining concepts and answering questions as they arise. Another example would be having an expert interviewer paired with someone who is practicing their interviewing skills. Having two people who are highly skilled in different areas paired together may result in conflict due to differences in style or work habits.

novice - expert
"Teach me your ways, sensei" - © Sony Pictures Entertainment

Novice-Novice pairing

This means pairing up developers who are both novices at pair programming. This has two advantages: 

The disadvantage of novice-novice pairing is that it limits how quickly both developers can progress their skills. After all, if both members of a pairing team are beginners, then there’s only so much either developer can learn—and even then things move slowly because teaching or explaining complex concepts takes time away from development work. 

Extrovert-Extrovert pairing

If your pair is an extrovert and you are also an extrovert, you will be able to keep each other motivated to stay on task. If one of you becomes distracted, it's likely that at least one of you will notice. You will inspire each other to solve problems and brainstorm innovative solutions. This pairing enables both of you to contribute equally without any awkwardness or pressure. This type of pairing is ideal for people who have not had much experience with pairing before. For example, if you do not know anything about programming yet but want some help with learning how to program, then partner up with someone else who wants some help as well. The two of you will have fun working together since you'll learn how to program together!

Introvert-Introvert pairing

When you have two introverts on a team, there’s no question that pairing can help them work better together. Each person will have their own strengths and weaknesses, so it’s a great idea to try and pair up with someone who complements your own skillset. This pairing style is especially effective for cross-functional teams where each team member has different roles to fulfill. Here are three guidelines to keep in mind when pairing with an introvert :

  1. Always start pairing during prework—and only if needed. Never start working on critical tasks straightaway; save these tasks for later when partner fatigue sets in.
  2. Aim to take turns driving—this way, one of you can stay engaged while the other takes notes or gives feedback.
  3. Switch partners often—the key here is to make sure neither of you get stuck with a teammate you don’t like or work well with. These tips will ensure that both introverts get enough focused time and energy, and everyone else gets time away from screen time!
Thinker
"I am not an introvert, I am a thinker"

Extrovert-Introvert pairing

The idea is that when someone who is an extrovert pairs with someone who is an introvert, they learn to quiet their thoughts and become more reflective. The introverts, in turn, practice speaking up and speaking out. There are two ways you can try extrovert-introvert pairing: At work or at home. If you’re looking for your partner at work, place a posting asking people to volunteer; make sure you ask specifically for volunteers (don’t just say volunteers wanted). Then put each person through a short interview process (in person or over email) to help determine if they’re actually interested. If all goes well, pair them! If it doesn’t go well, end it early.

We hope you enjoyed our article about Pair Programming and the different principles you can use when picking your pair programming partner. With this knowledge, we know that you can make the most of your programming sessions and complete projects with ease. 

Beginners Ground Rules for Remote Pair Programming

You’re about to try remote pair programming for the first time, congratulations!

Set aside fears and biases, here are some pieces of wisdom shared by our daily users, that you can rely on to make sure your first session is a success

Make yourself comfortable

One of the biggest benefits of remote pair programming, is that you get to share knowledge and learn from others, from the comfort of your own desk or home . Make sure you have everything you need, from a nice drink to your favorite backlit keyboard. If you’re pairing from home, remember that a good wifi connection is crucial for a smooth session. 

Another advantage of remote is to use a tool allowing you to work cross OS and IDEs, such as (you guessed it) Drovio

Comfortable
A little bit too comfortable?

Get rid of distractions

Your pairing partner needs you to follow and stay focused, so go ahead and click that “Do not disturb” button, whether that means activating the option on your computer or maybe letting the cat out of the room for a while? 

Turn your video camera on

Be prepared to shine bright and keep your camera on for your first PP sessions. First, it will help you start the session with proper greeting and encourage a more relaxed small-talk.  Moreover, visual clues will help you make sure you’re both on the same page. At some point you might notice your pair looking a bit confused or lost, but too shy to express it and ask you to slow down. 

Camera on
It's a bit too much, no?

Start small

Going from solo to duo programming is a big change, and your first Pair Programming sessions will definitely leave you exhausted. Set aside 30 minutes to an hour maximum for your first session, and keep the same timeframe for the first week(s). Once both roles feel natural to you, you’ll be able to get adventurous and plan 2 or 3 hour long sessions.

Also, make sure you pick up an easy task, one that you’re probably able to figure out on your own. The goal here is to understand the roles and dynamics of this new duo, not to get stuck on an impossible bug. 

Start small
Even Batman started small

Choose your partner carefully 

Senior or junior, experienced pair programmer or not... doesn’t seem to matter that much, as long as you start with someone you are comfortable with. Everyone is afraid of making mistakes and feeling judged. Surprisingly, we noticed that senior engineers tend to ask more questions than junior ones during PP sessions.

As pleasant as it can be to conquer this new territory with your favorite colleague, keep in mind that you’ll soon have to try Pair Programming with another partner, in order to prevent falling into some bad habits. 

Verbally agree on a common goal

This one may seem obvious, but it is necessary for both participants to make sure they understand and share the same objective. This will make more sense once the tasks get harder, as you’ll need to decide and validate the different steps needed to solve a bigger issue, that will help you stay on track later on. 

Common goal
The beginnings of a bromance?

Communicate respectfully

With great power come greater responsibilities.

As the Navigator, you’re naturally taking a more “judgmental” role, so make sure your Driver feels supported and encouraged. Resist the urge to shout “that’s not how it’s done!” and try asking “Why” or “How” questions instead. 

As the Driver, your main duty is to remember to also communicate: describe what you are doing and why. You should never go silent for more than 3 minutes. 

Remember to switch roles

It’s not easy to understand when you should switch roles, so pairing novices often apply the Pomodoro technique: work for 25 min, take a 5 min break, switch roles and work for another 25 min. This is perfect for a first session. 

Once you get more experienced, you’ll be able to determine WHAT will trigger switches instead of WHEN, although timeboxing can totally remain your method of choice. 

Have fun and celebrate small victories!

If you’ve taken time to research pair programming, you’ve probably found different techniques advocating for different rules and requirements. Finding your go-to method and rhythm of choice takes time, so make sure you’re actually enjoying the sessions, rather than feeling guilty for not following rules by the book.  If you feel frustrated at the end of a session, talk about it with your partner and try to understand what bothered you. If you feel proud of the work accomplished, celebrate, this is a big step! 

Enjoy
Enjoy!

Those simple ground rules will help you make sure your team is on the right track and reap benefits sooner than you think. If you’re feeling stuck, our team will be happy to help you, just drop us a message at contact@drovio.com and we’ll come back to you!

The Different Styles of Pair Programming

That moment when two developers are sitting across from each other, each staring into their own screen but working together to solve the same problem. That’s pair programming, and although it can sound strange at first, it’s an approach that has become more common in the world of software development over the last decade or so, with many developers swearing by its benefits. But how do you tell which type of pair programming to use, and when? Let’s take a look at some of the most common types of pair programming and see how they work!

The Driver-Navigator Style

In driver-navigator pairs, one programmer drives for a few minutes at a time while the other navigates. This is often done in coffee shops or open-space offices so programmers don't have to wait for others to arrive at their desks. There are also different styles of driving. For example, you can drive by telling your navigator exactly what code to write next, or you can drive by saying what you'll be doing next - then letting your navigator decide how best to accomplish that goal. The former style ensures that things get done quickly and accurately; but it takes practice to do well.

Pair Programming - Driver Navigator Style

The Unstructured Pair Style

This is probably what most people think of when they hear pair programming. The unstructured style, as its name implies, doesn’t prescribe much other than two people sitting down and writing code. This has many upsides: you can try out new techniques or languages to see how they work (and who better to learn from than your experienced coworker?), and there are no set rules for collaboration, meaning you can work at whatever pace suits you best. Unstructured pair-programming sessions are great for getting a lot done in a short period of time—you have twice as many brains on hand after all—but may not be great if you want someone else looking over your shoulder telling you what to do every step of the way.

Pair Programming - Unstructured Style

The Strong Style Pairing

This type of pairing usually consists in one developer who is designated as driver or navigator for a given time slot. That person will drive most of the interaction with writing code, while his or her pair will provide feedback about design decisions, ask questions about problem solving and check whether all requirements are met. This approach tends to be more efficient when you’re dealing with very specific tasks that require deep knowledge about a given domain or technology. It’s also good for beginners who may need guidance in some areas before being able to fully take charge.

Pair Programming - Strong Style

Ping-Pong Pairing

When pair programming, ping pong pairing means you and your partner trade off roles: One person writes code, while their partner reviews it. The driving and navigator roles will switch back and forth as well; however, because one programmer will know more about what to do than his or her partner, there is usually a bit of lead time to get things set up for that person to drive before they begin typing again. The end result is that both partners benefit from working on one task together without switching back and forth between tasks. It also creates a dynamic where neither partner can dominate or take control over another’s work. Although there are many different types of pairing arrangements, ping pong pairing is a great way to share responsibilities evenly.

Pair Programming - Ping-Pong Style

Backseat Navigator Style

The backseat navigator knows what he wants to do, but doesn’t always know how to get there. In practice, you may find yourself dealing with a backseat navigator in two ways: You both can write code, or you might be pairing with a developer who's looking over your shoulder and telling you what to type. If it's one-on-one pairing and you're a veteran programmer, a backseat navigator can actually help you solve problems.

Pair Programming - Backseat Navigator Style

Tour Guide Style

This style of pairing is used for two developers with different skill sets, such as a junior and senior developer. The lead is responsible for doing most of coding and is usually paired with someone who needs guidance, has specific knowledge that can be used, or just wants to see more. The junior dev focuses on improving their skills by asking questions and learning from what’s happening around them. This pairing is ideal when one person knows more than another about something like a new library or framework. Because both programmers are focused on writing code, there isn’t much time for chit-chat; however if either dev has questions about how something works they can ask before committing code.

Pair Programming - Tour Guide Style

Distributed Pairing

With distributed pairing, pairs are separated in different locations. For example, there may be two people in India and two in Canada; or one person in Los Angeles and another in New York. Pairing is carried out over computer networks rather than face-to-face. Distributed pairing can be used when individuals are located far apart, so no one is forced to travel long distances to meet face-to-face with their partner for pair programming sessions. One major benefit of distributed pairing is that it's convenient for all parties involved. It gives you access to better developers by providing an opportunity to work with specialists who live far away but have specific skill sets that complement your own skillset.

There are many different styles of pair programming. It’s important to understand these differences so you can find what works best for your team. The most important thing is that you choose a method that makes sense for your specific team, then dive in and see

4 Tips to Overcome Resistance to Pair Programming

While many people feel that pair programming is a great way to share knowledge, others may feel that it can be a waste of time or that it can be difficult to adjust to. So how do we overcome the resistance to pairing and make it a more of a routine in the development process? This article looks at four strategies that can help.

1. Understand Why People Resist Pair Programming

For many companies, the popular motto is often  "If it ain't broke, don't fix it". And who can blame them? After all, why change something that's already working? It's hard enough to get business owners and employees on board with basic agile concepts—why would you try and push them further than they're willing to go? A good starting point for pairing skeptics might be to ask their thoughts on pair programming. Ask them if they'd be willing to take part in some pair-programming sessions (if they've never done it before) or share with them an experience where someone benefited from pairing up. Alternatively, ask them what challenges they think could arise from pairing up. Consider these reflexions as an opportunity to raise awareness of what pair programming actually means. 

Take Things Slow: once management is on board with the idea of creating more efficient work environments through pair programming sessions, make sure there are clear guidelines about how things will work moving forward. For example, if managers are expected to take part in regular paired sessions with team members—this should be communicated both internally and by executives at press events outside of meetings (For example, our senior management takes part in weekly pair code reviews). Encourage Self-Selection: The people within your company likely have different skill sets and varying degrees of experience writing code.

Pair Programming - talk with your team members
Talk with your team members

2. Set Up Pair Programming Time

You can’t expect your team to pair program every day —it’s something that needs to be nurtured. One way is by giving your team regular pair programming timeslots. This could be once a week or once a month, but it's important that you set aside dedicated time for pair programming. Ideally, an engineer should have some practice before they're paired with someone. Explain why they're doing it: Frame pair programming as a skill everyone needs to learn and use regularly—like refactoring or testing. Everyone is allowed to say no at first if pairing isn't for them, but over time you'll want people who are willing and capable of pairing at any point in time. If possible, try to help make sure there aren't any holes in coverage when a pair isn't available. For example, give another engineer a list of things they can do while waiting for their next opportunity to pair. If you don't have enough engineers on staff, consider finding ways of pairing engineers up via video conference instead of sitting together in person. Take It In Small Bites: If you've never tried pair programming before then don't jump into it right away without taking small steps first.

Set up Pair Programming Time
Schedule regular pair programming timeslots

3. Make It Optional

It’s a common mistake to force teams who aren’t used to pair programming into it. To help people get used to it, make it optional. Let them know they can switch back if they find themselves too uncomfortable or something comes up at home that makes uninterrupted work difficult. It could even be as simple as letting them know they can come talk to you if there’s an issue—but let them choose whether or not pair programming is worth their time (and yours). As long as your team knows that pairing is optional, you should be able to overcome some of your initial resistance. Once in a while, let people in pairs do non-pair tasks when necessary.  If you have two design leads working on one project together, but only need input from one person on an idea, allow them to run away from each other and work independently for a while.

Pair Programming - Make it optional
Let your team members make their choices

4. Start Small

There are two important pieces of advice in regards to pair programming: start small and go slow. When you’re just starting out, try teaming up with someone on a quick, one-off task or project. Don’t dive into it for an eight-hour coding session—start with something that only requires an hour or two together. This way, you can make sure everyone is on board before really diving in. And going slow makes more sense than going fast when there’s so much resistance from all sides. Go slowly enough so people have time to get comfortable with whatever method you decide upon, whether it be pairing on a single problem or doing full-on two-person assignments for each person on your team every day of work. And even then, expect some pushback from “why change?” type of employees who just want their own space and quiet time at work!

Pair Programming - Start Small
Start small & go slow!

It can be difficult to overcome resistance to pair programming. But, as we’ve learned in this blog post, there are some simple steps that can help you make it easier. Try pairing up with somebody who’s new to it and see how it goes, or try pairing up with somebody who’s willing to help you learn. And remember: even if you’re facing some resistance, it doesn’t mean that your team won’t eventually love it. As you learn more about why people resist pair programming and how you can overcome it, you can help your team fall in love with it as well!