Chapter 3: Exploring Pair Programming Techniques and Styles

In the previous chapter, we learned how useful pair programming can be. We discussed how pair programming can be used to reduce task switching, offer better technical results, provide faster knowledge transfer, and how it can improve overall communication. We will now examine how pair programming can be even better by using collaboration-style methods that are appropriate for a number of typical (usual) contexts.

In this chapter, you will learn about several pair programming techniques and styles and how to use each of them. These techniques and styles are useful as they provide a framework for using pair programming effectively.

One pair programming technique distinguishes itself from another by the way each of the two partners works together, how active or passive each one of them is, what the role of each pair is, and how often the roles between the two partners are switched.

A pair programming style is defined by the way the two partners interact with each other. The partners can be equally balanced, one of the partners can have a more active role, or one can even be in the center of the activity. However, remember that some pair programming styles are not compatible with some techniques, so watch out when you choose from any of them.

We need to use each of the pair programming techniques or styles in the appropriate context in order to obtain optimum results; and by results, I am referring to productivity, work enjoyment, and learning efficiency.

In this chapter, we will focus on the following topics:

• Understanding pair programming techniques
• Improving pair programming with styles
• Organizing pair programming
• How often do we need to pair?
• Exploring different communication methods
• Pair programming best practices
• Pair programming anti-patterns
• Boosting productivity with remote pair programming

Understanding pair programming techniques

There are several usual pair programming techniques that can be used for different purposes and with different effects. We will go into greater detail regarding the most popular pair programming techniques. Every technique has its place in a certain context. Additionally, it's useful to use some techniques in some cases and other techniques when the situation changes. We will discuss, in detail, when each of these techniques is useful.

Note that there is a generic setup that you need to take into account, no matter what technique you use: ensure that you have two keyboards, two mice, and a monitor at the same distance and angle for both partners. That is all; we will detail any additional requirements for each specific technique as we go further.

Most of the time, there is a rotation between the two partners. When using any of these techniques, both partners will have a specific focus. During a rotation, this focus changes between the partners. We will detail rotation specifics for each particular technique as well.

Each tool or technique also usually has its own set of advantages and disadvantages, and we will detail these as well. In order to be effective, it's not only important to choose the right tool for the job but to also know your tools from experience.

All of these techniques need to be practiced, understood, and can even be forgotten to the point where you just choose the appropriate one by following your instinct. These are detailed descriptions that have a didactical purpose and might not be complete, as it's difficult to include every angle without the reader getting bored or the author splitting hairs.

The Driver-Navigator technique

As the name suggests, in this technique, we have two people and two roles: the driver and the navigator. You can liken this technique to racing cars, where the driver holds the wheel and the navigator is expected to explain, upfront, the obstacles and dangers on the road.

The driver is the one writing the code and focusing on the small details. Ultimately, they are in charge and make all of the decisions.

The navigator observes the driver writing the code and focuses on the long-term decisions. Additionally, the navigator can suggest ideas, come up with alternative options, and show the potential risks, dangers, or fallbacks of the current code.

Setup

In this scenario, the driver keeps the keyboard and writes the code. The navigator doesn't require a keyboard but a second computer, where they can search for resources, find answers, refer to the relevant documentation, and more.

Rotation

When using this technique, rotations are done very seldom or not at all. To begin, try to switch roles after every finalized task, which can take from a few hours to a few days. After a few pair programming sessions, you can also begin switching within the same task.

Advantages

The advantages of this technique are as follows:

• Fewer, or no, rotations generate less context switching.
• The driver can focus on writing the code for a long time with the help of the navigator.
• For the navigator, this can be a useful learning context for better communication. Since the navigator can only suggest ideas, they need to be able to efficiently explain how short-term decisions will affect the long-term evolution.

Disadvantages

The disadvantages of this technique are as follows:

• Because of few or no rotations, it can be tiring for the driver to focus on writing the code. Bigger and more frequent breaks could help in this situation.
• It can be frustrating for the navigator to not be able to put their hands on the keyboard. However, as we mentioned earlier, this can also be an advantage learning-wise.
• This technique is not the most effective way of getting things done. Sometimes, the navigator suggests good ideas, but without communicating them well, the driver will continue with their own ideas.

When to use it

This style is useful when you are beginning to pair-program. It's useful to create a common way of doing things, with people adapting to one another. There is not much change from usual programming and because of that, it's easier to get started with it.

When I start pairing with someone new, I instinctively start with Driver-Navigator. It's my go-to starting approach. Then, I might adapt the technique, taking into consideration what my new pairing partner likes and what our task is going to be.

You can call Driver-Navigator the snowball of advancing knowledge. Once, I was pairing as an external consultant to teach different topics such as unit testing and dealing with legacy code. In this particular scenario, I was paired with Peter, an experienced programmer. I started by briefly explaining how I would like to pair. For the first hour or so, I wanted to balance the time between me and my pair, starting with Driver-Navigator but making sure that we rotate often enough to gain some momentum with the learning process. Usually, my new partners find it easier to start with Driver-Navigator: as I show how to write a unit test, they show the business and code details. For me and for my pair, it's a game of rolling a snowball, making the snowball bigger and bigger as we learn from each other during each rotation.

Remarks

The Driver-Navigator technique is, from many points of view, the opposite of Strong-Style pairing. Strong-Style pairing means that the driver is just a smart keyboard, and the navigator is extremely active and constantly explaining to the driver what to do. The name "Strong Style" comes from the fact that the navigator is strong in an unbalanced way, and the driver doesn't have much liberty. Strong-Style pairing can be described by inverting the roles that we just discussed in the Driver-Navigator technique. We will dive into more detail about Strong-Style pairing later on in this chapter.

Note that you can also have the driver be the beginner, and then the navigator takes on the role of an active technical coach. This first approach will generate more pressure on the beginner. That is why the navigator needs to have good coaching and training skills. Being able to explain things efficiently, going into detail about why to do certain things, and convincing the beginner to try something are all tools that need to be used here.

Alternatively, you can have the driver be the advanced one of the two, and the navigator will learn by watching the driver operate. This second approach can generate less pressure for the beginner, but it might result in fewer learning outcomes. Additionally, this second approach can become very difficult for the beginner if the driver works really rapidly without explaining much. While it would be useful to see, not much learning will take place during those hours of pairing.

The Pairing-Trainee technique

This technique is used to teach programmers how to start using pair programming. No matter the programming experience of the programmer, this technique works for adding this pair programming tool to the programmer's tool belt. It's important to increase the confidence of the trainee, so the trainer must behave in a gentle and open manner. This is so that they can build up the trainee's interest in coding as opposed to judging their current skills.

Setup

For this technique, it is helpful to have two keyboards, two mice, and two monitors. However, note that the trainee will drive most of the time. The second keyboard can be used by the trainer for short periods of time, just to show something small that is extremely useful in the context, such as a shortcut or a way to make the code elegant more quickly.

Rotation

For the first few sessions, we shouldn't rotate within this technique. The driver will always be the trainee.

After the first few pair programming sessions, we can start rotating once every 30 or 40 minutes and gradually decrease the time as needed. Because of the decrease in rotation time, we can then naturally introduce the Driver-Navigator technique.

Advantages

Advantages of this technique include the following:

• The most effective way to understand how easy and fast it is to use pair programming is by pairing with someone who is advanced in pair programming.
• While pairing with someone who has done this for a long time, you can learn tricks based on the current need, choose the best approaches, take breaks when necessary, and more.

Disadvantages

Disadvantages of this technique include the following:

• It might feel forced, or unnatural, at the beginning for the trainee. We need to address this potential issue straight away and be very open about future pairing sessions. Ask the trainees to voice all of their concerns upfront and then answer them. In this way, we can at least minimize this feeling of working in an awkward manner – something that they aren't used to doing.
• Initially, programmers might feel afraid that we will assess their skills and code and judge them based on this. In order to mitigate this risk, we need to remain friendly and explain, in depth, what we are going to do. More importantly, we need to reassure them that we are not assessing their technical skills or their code. Sometimes, people seem to think that when someone new comes and works with them, they will judge them. So, set the rules of the game straight from the beginning: we will work together to learn pair programming and no judgment or shaming will occur.

When to use it

This is a very good technique to use during the first few sessions of pair programming. Once the trainee pair-programmer has learned the movements of pair programming, this technique will no longer be useful and we can then move on to the Driver-Navigator technique. Only once the ideas behind how to pair, how to communicate, and how to work together in a pair are clearly understood, is it a good idea to switch to another pair programming technique.

In an organization where I was working as an external trainer, Iris was pairing with John. Iris was a senior programmer and John was a junior programmer. Iris was extremely experienced in pair programming and many other techniques. I spoke to Iris about how to approach the pairing session with John, and I explained to her the Pairing-Trainee technique. At the time, I was working with someone else, close to Iris and John, and was observing what was happening. John was almost full-time driving. Once, it so happened that Iris wanted to show John how to extract a method with the automated refactoring tool. Then, nearly half an hour later, Iris took the keyboard again to show him how to structure a class better so that it respects the team's coding standards. The rest of the time, Iris was very patient and calm, explaining to John how pair programming worked and working according to John's speed. Of course, with John being a junior programmer, his speed was much slower, but Iris didn't push him at all.

After their pairing session, which took around 70 minutes, I asked John how he felt. He said it was intensive, but he liked it because he was able to learn a lot and also learn from an experienced programmer who was very likable. Iris told me that it was challenging to keep such a low rhythm, but she understood its importance when being paired with 
a junior programmer.

Remarks

This technique is a good icebreaker into pair programming. This is because, quite often, starting directly with the Driver-Navigator technique can feel like too much to take in at once since there are so many rules and guidelines to follow. When teaching or learning something new, it's always a good idea to use a gradual approach and keep adding more difficult elements once the previous elements have been absorbed.

The Beginner-Advanced technique

This technique is about teaching a programming beginner a specific topic using pair programming. It's not to be mistaken with the previous technique of Pairing Trainee.

Setup

As usual, two keyboards, two mice, and two monitors make a good setup to begin with. Even if the driver is always a beginner, the navigator can point things out by showing something or writing for a brief period of time.

Rotation

To begin with, there are no rotations. For the first few sessions, the driver will always be the beginner. However, after a few sessions, we can introduce some rotations if the advanced programmer considers that learning will be more effective in this way.

Advantages

The most effective way to learn something new is by using pair programming. This technique leverages pair programming to allow you to teach and learn new skills, tools, and practices. In this scenario, the two partners are focused on what they need to do, and focused experiential learning is one of the best options when teaching someone something new.

Disadvantages

This technique might feel forced or unnatural at the beginning for the trainee. By managing expectations before starting the pairing sessions, these feelings of being forced will decrease. Additionally, a good approach is to explain, step by step, what will happen, how the pairing will take place, what its advantages are, and acknowledge that it will be extremely tiring.

When to use it

This is a method that I mostly use when I am being a technical coach, and I need to explain various tools or techniques to beginner programmers. The technique works very well when an experienced programmer, or a team leader, has a junior team member and the new team member needs to learn a lot of new tools, practices, and skills.

Programming is best learned by practicing it. And what better way to practice than with an experienced programmer by your side? You can get guidance from them when you make mistakes, and you can also see how other experienced programmers work.

After a training session, I always recommend what we call "training on the job." This means that we can apply our knowledge directly in production, on the code base of the trainee, and in the role of the trainee. Once, I was pairing, for the first time, with a junior programmer, George, at his desk. The pairing session followed a unit testing workshop that he had attended a week prior. We started by looking at his tasks for the near future, and then we agreed to work together on one of the tasks. As we had followed a workshop, I played the role of the teacher who asked George to apply again, in production code this time, the knowledge and practice acquired at the workshop. In this scenario, I'm observing, asking questions when I feel George's actions are unclear, and then assisting him when he gets stuck. When George correctly follows the steps that he had learned in the workshop, I just acknowledge the good approach and don't say much.

This example of pairing with George often happens after a workshop or when you are teaching a programmer something new. It's a good approach to use to help you solidify the acquired knowledge in the production code of a team. This is because it often happens that a classroom code base is easy to tackle, but the production code base is another beast. George is a lot more confident about applying the new technique after a couple of 2-hour sessions of pairing with me, using the Beginner-Advanced technique.

Remarks

This technique is different from the Pairing-Trainee technique. Here, we talk about teaching a junior programmer how to code, while Pairing-Trainee is about teaching programmers of any level how to use pair programming.

The Beginner-Beginner technique

This is a technique when you put two junior programmers, or beginners, together to pair with each other.

Setup

Typically, the setup for this technique is two people at a computer with just one keyboard and a mouse.

Rotation

Rotations are not as often as you would expect with experienced programmers – perhaps every 10 or 20 minutes.

Advantages

I don't see many advantages to this technique. Instead of letting one experienced programmer struggle, you have a pair of people struggling. And struggling together means that they might, maybe, get something done.

Disadvantages

There are many disadvantages to this technique:

• First of all, the two partners won't be able to learn that much. They will struggle a lot with not much result.
• The two partners will struggle a lot in an attempt to produce something, which is frustrating. Additionally, if it's their first working experience, they are likely to remember it for the rest of their lives.
• Struggling could lead to a lot of negative opinions about the methods that the two partners are using. In fact, they might even consider pairing as a negative thing from the onset and, by extension, the code base they are trying to get, the IDE, or any tool that is connected to this experience.

I wouldn't like to have a first-time learning experience like this, and I hope you wouldn't want that either!

When to use it

Please don't use this technique; it's more of an anti-pattern.

I was invited to an organization to evaluate their overall technical management, tools, and practices. During these gigs, I spend most of the time talking to as many people as I can and taking time to observe the workspace of the teams. Here, I noticed that one team had more junior programmers who had been hired only recently. Instead of having a formal and informal induction from more experienced programmers, the junior programmers were left to learn by themselves. As they were not enough computers at that point, two programmers shared the same computer and tried to get their heads around the code base. After seeing this, I asked them to have a chat. They said that everything seemed to be really confusing, and they already weren't enjoying working there. This is how counterproductive Beginner-Beginner pairing can be. After one year, all the junior programmers left the organization. It's no wonder, considering how they were treated by the hiring organization during their first few weeks.

Remarks

I wouldn't recommend using this technique.

The Ping-Pong technique

Beginning with from Driver-Navigator, we have two roles that change relatively often. The driver is always in charge, and the navigator can suggest ideas. But the two roles change quite often.

Setup

For this technique, you will need a setup for two people: two keyboards, two mice, and ideally two monitors that are connected to the same computer with a mirrored screen.

Rotation

There are several ways in which to rotate with this technique, and they are explained as follows:

• Timeboxing: Using a timer, the partners change when the timer rings. The usual time slots are between 5 and 10 minutes. The condition is that when you pass the keyboard, the code works and you have finished your current idea.
• Test-Driven Development (TDD): In TDD, you follow the Red, Green, Refactor cycle. With Ping-Pong, one person always writes a test, and the other person implements the test and refactors it. Then, the second person writes a test and gives the first person the opportunity to implement and refactor it. It's Ping-Pong because you always pass the test around to your partner, in the same way that you would hit the Ping-Pong ball to go to the other side of the table.
• Task bases: The pair splits the work into small tasks of no more than 30 minutes each. Then, each partner gets to be a driver or a navigator, one after the other. This technique works really well because you can see real progress, and it's comforting to cross tasks off a list and say they're done. However, it can be difficult if you are not used to splitting tasks into such small increments. Anyway, practicing to split tasks in small increments is a good lesson, as a by-product of the technique itself.

Advantages

As both partners can write code for an equal amount of time, on average, this technique tends to be more effective and can even generate better results more quickly.

The fact that the partners switch more often forces them to take smaller steps. This means that you cannot start a complex change for 3 or 4 hours, which will most likely get you stuck. From this point of view, it's an advantage that the partners learn how to decompose a bigger 3 or 4-hour step into smaller 5 or 10-minute steps that allow them to create a flow. You can minimize the time lost from getting stuck and trying to fix things.

This can be a very useful method to learn TDD, as it forces you to think about how the code evolves in small iterations. This pairing technique helps to set a discipline to the Red-Green-Refactor cycle, and it's a good addition to TDD.

Disadvantages

Because of the frequent rotations, this technique can lead to context switching and the partners becoming tired more quickly.

Additionally, when the partners don't agree on what path to take with their solution, the code can get repetitive, and not much gets done. It's a learning process for both partners, usually a much-needed learning process, but it can still be ineffective and frustrating.

When to use it

This is a good technique for more experienced pair programmers. Usually, after a few weeks of using the Driver-Navigator technique, I would introduce the Ping-Pong technique for a while to see what the team thinks.

When using TDD, Ping-Pong is my go-to pair programming approach. Once, I was pairing with a few advanced programmers, who wanted to boost their TDD practices. Naturally, I asked them to use Ping-Pong. Our sessions were fun, energetic, slightly tiring, but very fulfilling for all of us. We saw progress and could also bounce ideas while changing the roles in our pair. At the end of the session, which took around 2 hours all in all with some breaks, we finished with a debrief. The main comments that were made during our debrief were that it was intensive learning, we didn't know how the time passed so quickly, and working like this really made sense.

Remarks

This is an interesting approach that can lead to a relatively intellectually intense activity of trying to write a good test, with an equally good next step. It allows both partners the opportunity to look at the short term and the long term, and it creates the premise for good software design.

Summary

So far, we have discussed pair programming techniques, where they are useful, and how they can be used, along with nuances for each technique. The Driver-Navigator technique is a classic approach to pair programming, while the Pairing-Trainee method helps programmers learn how to use pairing. The Beginner-Advanced technique is a method of teaching a new topic by using pair programming. The Beginner-Beginner technique is an approach that I don't recommend, and Ping-Pong pair programming is especially useful with TDD. Try using these techniques in the appropriate context. And what better way to understand these techniques than to experiment with all of them, practice them, and then decide on the right method to use yourself. However, don't do that just yet! Let's examine how we can improve the preceding techniques with pair programming styles.

Improving pair programming with styles

A pair programming style is a specific way to behave while pairing. It is an addition to the techniques that we discussed earlier. Remember that not all of these styles are compatible with all the techniques that we mentioned. Choosing the right style for the right context can boost any pair programming session.

Consider the following working styles: when working in a pair, your style could be to let your partner to work as they like or say only a few clear, direct comments. Alternatively, your style might be to guide everyone during every moment of the process. I have even heard people who choose the style of not interfering and taking every chance to explain something new to their partners at the right moment, mostly when the code is in a stable state.

So, a style is a mix of how involved you are, how much space you give to your partner, how much you step up, but also how you communicate. Let's explore each of these styles in more detail and find out when is best to use them.

Unplanned pairing

This is the most common type of pairing for when you are stuck, you need some advice, or you want some expertise from a colleague. Typically, you ask if they can help, and you sit at the same desk with the problem in your head and start talking through it. In this scenario, you don't have clear roles; rather, the focus is to solve the particular problem that was raised.

Many programmers don't know that this is pairing. Instead, they think of it as asking for advice.

Pros

Unplanned pairing comes naturally; there are no specific rules to take into account. It's easy to set up and not much overhead is required.

Cons

This style is not necessarily the most effective way of pairing. Usually, it just involves a few team members who start working with each other.

The pairing approaches of different people might diverge from the most efficient method. It's very difficult to see what needs to be improved when you are paired with people who do the same work as what you do.

When to use it

This technique, probably, works best in its natural form rather than not happening at all. It's not ideal; however, it's a start, and it gets people used to the idea of working in a pair as opposed to working solo.

When people start unplanned pairing and like it, it's just a matter of discovering a better pairing style and they learn it at once. However, when people have used unplanned pairing and have felt awful, been criticized, or been mocked, then it's going to be a lot more difficult to make them want to pair again, even if they are doing so in a different context.

Traditional pairing

Traditional pairing occurs when you have two partners in front of the computer and they work without much thought about anything else. Typically, people pair with colleagues they like to pair with, and they tend to stick to one another.

This is a form of planned pairing, the simplest one, and it works when one pair says, "I want to pair on this topic because we will go faster," or something such as "You know this topic better, so I would like to pair with you in order to learn it as well."

You might have one person typing for days and the other just observing. Or, you might have a rotation in the pair. It varies depending on the people involved and how they feel at that particular moment.

When you are focused on getting things done, the more experienced person will take the lead, and the other will just follow for long periods of time. This is a good approach as the more experienced can work at a faster pace and will depend on the partner to point out any syntax mistakes or small errors when needed. In this way, the observer can learn how to get things done in that part of the code base, or with that tool, or learn more about that part of the domain logic.

When you focus on learning, the experience can vary depending upon the fact that you can be a programmer or not. Nevertheless, the focus, in this case, is on learning and not on getting things done. You don't always have that clear focus, as you might divert your attention from the end goal in order to show some details of the tool or of the system that you are teaching or learning.

Most of the time, one of the partners will decide to take the lead in the pair and make most of the decisions. Usually, the more experienced, more senior, or more outspoken partner will take this role. While this can be a good thing, as soon as communication becomes just a one-way street and their partner is constantly at loggerheads with them and not getting through, it starts becoming a problem.

The quality of communication depends on the two programmers involved. Sometimes, it can get tricky with arguments or fights on how to do a certain thing. However, it can also be a smooth process and flow without any incidents. Typically, for untrained traditional pairings, there is very little understanding about how to communicate properly and, additionally, how important communication is when doing pair programming.

Compared to other styles of pairing, traditional pairing is quieter. The driver leads the way, sometimes explaining things, but there isn't much debate or discussion.

Pros

It's good to pair up, get things done, or learn with this style because you will do these things more quickly in a pair than if you were working in isolation. Traditional pairing is a good approach when you need to learn a new business domain, a library, or a new tool or technique.

If we consider the point of view between the learning quantity and quality, it might be the most effective method of pairing.

Cons

As each person might do what they feel is necessary, without much experience of pair programming, they might make wrong decisions that create tension in the pair.

Quite often, the leading partner can make decisions without explaining them too much or too well, and this can generate tension or frustration for the other person.

Traditional pairing is not the most effective way of pairing, and it is mainly judged by the coding outcome.

When using traditional pairing remotely, it is difficult to stay engaged. Since the navigator doesn't have a very active role, they can easily be distracted, or even lose focus while the driver is focused on getting something done. To overcome this shortcoming, the driver needs to always explain what they are doing in greater detail and often ask for feedback from the navigator. Additionally, the driver needs to try to include the navigator in the conversation in order to heat up the pairing activity.

Best suited for

Beginners in pair programming benefit from trying this style. It's easier to approach. Not a lot of social and communication skills are needed to use this style as compared to the other pair programming styles.

Elastic pairing

Elastic pairing is a situation when any pair can take the keyboard and continue.

This is a pairing style where decisions are made with the consensus of the two partners. The two partners know how to communicate, can briefly explain their points of view, and accept the other's argument. The partners try to find the best solution for the problem at hand rather than trying to impose their opinion based on ego.

There is a good rule with elastic pair programming: when someone is watching you, you need to work at a slower pace. Quite often, you need to slow down, and if you go any faster, you are likely to make mistakes. For beginners to pairing, slowing down might feel like you are being less effective. However, to people who are advanced in pair programming, slowing down feels like the right thing to do. When you slow down, it's less likely that you will break things, get stuck, or make mistakes. Additionally, you can start to build up a state of flow, which you can keep at that pace for long periods of time.

This style feels very natural; It's similar to two old friends talking to each other and never wanting to stop. Because of that, it often leads to a good flow, good progress, and a higher quality of product. When you are pairing, you might think only one hour has passed, then look at the clock and find that many hours have passed, which means you were, or still are, in a state of flow.

Elastic pairing means that you stop implementing the traditional driver and navigator roles. Each partner can be more upfront or at the back of the programming stage, depending on the context. The two partners behave without formal roles, drivers or navigators, and without any of the two partners getting annoyed.

With elastic pairing, you will often ask your partner for feedback and whether they want to continue being the driver. There are even moments when both partners are driving – each one of the two partners writing very small batches of code, such as a few words or letters.

So, elastic pairing feels as though you are working with someone whom you have known for a long time, and you can complete each other's words, sentences, and expressions.

For me, this is the best expression of collaboration between equal peers. It allows you to work together with respect for the other's point of view, care, and empathy for what the other person thinks. It involves a mix of technical traits, communication, and social types of behaviors, which generate a very productive and almost ideal working environment.

When using elastic pair programming, it's helpful to set up rules such as no phones, no distractions, and to remain involved even if you are not writing code.

Pros

This style is one of the most productive ways of working for experienced and senior programmers who are open to pairing with anyone from their team.

When working in this way, that is, with elastic pair programming, work becomes fun. And with great enjoyment usually also comes great productivity. The satisfaction of getting things done also generates high-quality products and reduces any tensions within the team or pressures from outside the team to get things done within a particular timeframe.

Elastic pair programming feels more engaging for each partner. There isn't any point where you will get bored or feel that you are being left out. You are required to be there, with a focus of 100%, and if you aren't, your pair will feel it immediately.

Cons

You need many skills, mostly non-technical, to be able to achieve such a balanced method of pair programming. Far too often, programmers are only taught technical skills in organizations; however, social and communication skills are not considered to be that important. This is a management mistake that can affect the whole organization and prevent the efficient implementation of approaches such as pair programming to their full extent.

It is debatable whether you can only have a few people in a team using this approach. Usually, a few people who really like each other become friends and start working together. This situation might be problematic, as you don't want to have islands of boosted productivity, based on self-selecting groups, and the rest are left to do the best they can, just because they don't fit into that group.

Elastic pairing is not useful in certain situations, for example, if you want to learn about the business domain or when you are pairing with people at different levels of seniority. Traditional pairing will help you to learn more about the domain and the technologies that you are focusing on.

If you haven't used elastic pair programming before, it is more difficult to use it remotely. It can be especially difficult to enforce the no-distraction rules (for example, no phones, chats, or email) we spoke about.

When to use it

This is best suited for experienced programmers, who have paired for a while and greatly appreciate each other's opinions at any given time.

Strong-style pairing

Strong-style pairing is very different from the other styles we have mentioned so far, and, sometimes, it is the opposite of other pair programming styles. In this pairing style, we have the driver who writes the code and focuses on the small details, in the short term, but cannot decide anything. Then, we have the navigator who makes all the decisions, focusing on long-term decisions. We sometimes say that the driver is a smart keyboard, who is only doing something when they are told to. The only reason why the driver focuses on the smaller details is to do what the navigator has in mind while doing it.

Sometimes, you might find that the two don't understand where they are going. At that point, when something is unclear, the two need to stop working and have a dialogue about what they need to do next.

Similar to traditional-style pairing, both the driver and the navigator have the same focus, to try to solve the problem as fast as they can with the highest quality possible.

This is the most difficult style of pairing, especially for the navigator who is taking many responsibilities on their head. You can think of this as though we are forming a pair programming body where the navigator is the brain, and the driver is the hands that touch the keyboard. The reason behind this is that in order for an idea to become functional, it needs to first pass through someone else's brain.

It's not always the case that an experienced navigator knows what to do next. Sometimes, the navigator will try things and develop the code in certain directions just to see where it goes. It's usual to do that when you are solo programming. However, in this situation, the driver might feel that the navigator doesn't know what they are doing. That is why the navigator needs to ask the driver for some trust, particularly in the short term, while trying things that might seem weird. You need to do that as a navigator because when your pair doesn't trust you, it's difficult to explain, in logical terms, something you cannot yet grasp to its full extent. That is why the navigator experiments with different things, in order to better understand a certain detail of the potential code.

The navigator needs to possess extremely good communication skills. It's not just about what to say, but also how to say it, and when to say it. Additionally, it's about the chain of different small communications that add up and make things clear to the driver in terms of what to do next.

One of the most important guidelines to succeed with Strong-Style pairing is that the navigator needs to communicate gradually, from generic to more specific details.

A guideline for communicating to the driver is to use three steps, as follows:

1. Intention:

   First of all, the navigator needs to express their intention. This needs to be something generic, yet clear. For example, "I would like to implement an A* search algorithm for this list," or "We need to use a strategy pattern for these cases."

2. Location:

   After that, mention the location. You could say, "Line 34," or "Line 34 and a half," if you want the driver to insert a new line after line 34. If you need to create a new file, say something such as "Search namespace, algorithms folder."

3. Details:

   Then, only at the end, after expressing your intention and the location, the navigator should delve into the details. The details can be more or less, depending on the driver. Sometimes, it's enough to simply say, "Please implement this interface and all the methods from it for class X." However, if your driver is a novice, then you need to go into more detail by saying, "Create a new class, implement the interface to the new class, generate all the methods from the interface with the help of the IDE, implement first the doThis method, then the doThat method, making sure you respect the contract of the interface."

   Very often, I see the second approach being used when it isn't needed, and the driver already knows what they need to do. This is a waste of time, but it can also be frustrating for the driver, as they might feel like they are less useful than a smart keyboard.

Communication becomes easier to manage once you use these three steps. Remember, it's not something that you do naturally, and it needs practice and perseverance from the navigator. Additionally, it brings a lot of clarity and flow, and it reduces any friction caused by the driver being unclear on what to do next.

The driver is a smart keyboard, as mentioned earlier. This means the driver needs to ask for clarification when needed, but they cannot make any decision on their own. Communicating well is as important for the driver as it is for the navigator.

All the decisions come from the navigator. It's an interesting feeling being the driver, as you focus solely on writing the code, and you need to empty your mind of the larger-scale decisions. For some, it's great fun to pair like that, while for others, it feels like they are neglecting their capabilities on purpose. And that's not necessarily a bad thing, to focus with less bandwidth, less brainpower, and just do some simpler and smaller activities.

The partners can choose to rotate with each other more or less often in Strong-Style pairing. You can use the timeboxing technique or rotate after bigger independent chunks of code start working, and you can pass the navigator's role with a clean slate to the driver.

Rotation comes with more context switching compared to the other pair programming styles. The driver needs to remove themselves from the simpler, more comfortable role of a smart keyboard and into a deeply involved strategist and designer role as the navigator.

Pros

This pair programming style is very useful for knowledge transfer. It's mainly used by technical coaches, team leaders, or very experienced senior programmers.

When using Strong-Style pairing, the navigator is far more engaged than in other pair programming styles. Since the navigator becomes the front figure of the experience, they need to be very present and active.

Cons

If done wrong, this style generates a lot of frustration. And the partners that have experienced it, even in the wrong way, might never want to come back to it, even if after a while.

Using this style excessively, that is, on a regular basis for many weeks, might make the style less effective. This is because the people who were involved have started to understand more about the basics of what the partners were doing. So, switching to a different style where the partners are more equal, or having rotations of between 5 and 15 minutes with Strong-Style pairing, would be a lot more beneficial.

When to use it

Strong-Style pairing is suited for any programmer in the driver's seat. However, for the navigator, a very experienced programmer, team leader, or technical coach is needed. You can definitely try Strong-Style pairing without a very experienced navigator, but there's a big risk that things will derail fast, and many would consider that this way of working doesn't make much sense.

Strong-Style pairing is useful when people are very used to their code but don't know how to refactor it. In this situation, it is very useful to use Strong-Style pairing because the driver would know how to navigate around the code, but they won't know how to refactor it or use a specific coding technique.

Once, I was at a client site and was pairing, for the first time, with an experienced programmer. I was pairing with the kind of programmer who would prefer not to give the keyboard away. In this situation, Strong-Style pairing was preferable, as I saw that he was very attached to his tools, keyboard, and mouse. I started working with him, being just a shadow, and asking simple clarification questions when I was not clear as to what he was doing. Little by little, I started having opinions about what we could do better. Through small steps, I started taking control of the development direction, simply by suggesting ideas and discussing them with my partner. I swiftly became the strong partner and started helping my partner without touching the keyboard for even a moment.

Summary

Pair programming styles make a key difference to both a programmer who uses pairing and also a well-versed programmer who can use pair programming effectively in a variety of places and contexts. Constantly adapting to your partner is one of the essential characteristics of an experienced pair programmer, and pair programming styles occupy an important role in that. After spicing the pair programming techniques with styles, we can now look at how to organize ourselves for pair programming.

Organizing pair programming

An organization can think about implementing pair programming in many different ways. Naturally, people who are friends, or work well together, will pair with each other. Additionally, people who are outspoken, or extroverts, will find each other and start pairing up. But what do we do with the rest? Maybe there are individuals who want to pair-program in the organization, but they are afraid to start, or they are embarrassed to pair with that programmer who is very good and thinks they are too good for them. Imposter syndrome happens everywhere in knowledge-based work environments and affects any knowledge worker, and programmers are no exception.

So, we need to do something about this situation in order to generalize pair programming in the organization. In the following sections, we discuss a number of commonly used options to generalize the use of pair programming in any organization.

Round-robin pairing

Round-robin pairing is where every team member partners with every other team member, in a clear order.

First, we create a list of tasks, and the first pair then picks the first task and this continues with the following pairs and tasks until the list ends. For the next set of tasks, you change partners, making sure that none of the original partners are the same. It continues like this until you return back to the initial partner structure. There are no individual tasks; there are just team tasks that get (self)assigned to partners. Of course, you might want to make sure that the tasks are (self)assigned in a way that the pair can solve the tasks, in a timely manner. Sometimes, we have specialists in some areas, or we have people who have never touched that area of the code.

This way of organizing pair programming is effective, transparent, clear, and easy to use. However, bear in mind that it won't please everyone. You might start having conflicts because Jane doesn't want to pair with Julia. Or that John would like to pair more often with Jane. For some teams, in some contexts, round-robin pairing can feel forced, even coerced. Because of that, it is important to get the approval of the whole team before you start using it. It's OK to use it one or two times as a pairing experiment, but then you need to make a short retrospective and ask the team whether they like the method and whether they would like to continue with it.

Promiscuous pairing

Promiscuous pairing can be described as an unselective approach in which you use an indiscriminate manner to find partners within the team. Promiscuous pairing means that we want everyone to pair with each other and to switch partners as quickly as possible. It's not as strict as round-robin pairing, but someone will oversee the process so that you don't have selective pairing or just parts of the team are promiscuous.

This is another method of spreading information and practices around the team. With these rapid changes, the partners will receive the same information more quickly than they would with other approaches to organized pair programming. The partners change relatively often, and you can pair with a few people daily, even on tasks that another pair has already started beforehand. In comparison to round-robin paring, here, you would pair instead in timeboxes, but that's not necessarily a rule. If you have very small tasks that can be done in one or two hours, then you can use promiscuous pairing without needing to continue another pair's task.

Promiscuous pairing is sometimes difficult to accept. It might sound crazy to change partners every couple of hours, and it can feel unstable and unreliable, among other things that generate instability. Additionally, as with any situation, people might feel forced to pair with someone they don't like to work with. This latter situation can definitely cause tensions. Nevertheless, it's important to learn from everyone, and any team leader or senior programmer in the team should try and encourage any colleagues to be open-minded about the pairing. Any personal situations of incompatibility need to be resolved by taking into account each specific context, considering the current situation and the history of the pair. There can be many reasons, historical or personal, that generate this current incompatibility. Some of them can be resolved, while others are very difficult to solve.

Selective pairing

You can describe selective pairing as pairing with your friends and neighbors and ignoring the rest. This is the natural way to start pairing. This is of course, applicable where anyone would choose someone who is open to working like this. Even if you wish to convince your colleagues, some of them won't want to work in a pair. So, in the end, you have a self-selecting group of people who will work by using pair programming.

This is a very good first step toward pair programming. However, leaving out a part of the team is not a good idea, at least in the long term. You will end up with two teams in one, that start diverging their practices, beliefs, tools, and more. After working like that for a while, you will need to see whether all the team members want to pair, at least on some type of tasks, or whether it's a better idea to split the team into two: a team that uses pair programming, and a team that doesn't use pair programming.

We need to acknowledge that pair programming is not for everyone, at least in the beginning. Some people, the early adopters, want to take a chance with this new idea. Howver, there is also an early majority that might be formed, if the early adopters create compelling arguments. Then, you might convince the remaining workers to start using pair programming. It can take weeks or months. And in the end, you still have laggards who don't want to pair. And that's fine. Pair programming isn't necessarily for everyone. We don't need to force this practice but show how it works for us, and invite people to try it for themselves.

Many teams keep using this approach for years. And even if it's suboptimal, it's still better than no pairing at all.

We have discussed a few typical situations of how to organize pair programming within an organization. We didn't go into too much detail, as it's not the main purpose of this book. However, I highly encourage you to learn more and ask for help from a technical coach when organizing pair programming for the first time. The saying, "The devil is in the details," is very appropriate to the task of organizing pair programming, and even an experienced technical coach can make mistakes when dealing with a new team. After we have organized ourselves, the next question arises: How often do we need to pair? Let's review some answers in the next section.

How often do we need to pair?

This is a very common question that gets asked when using pair programming for the first time. The answer to this is very difficult since it depends heavily on the context of the organization, team, product, code, features, time available, and many other aspects. Let's answer some of the more common scenarios.

Should you pair for the whole day?

Especially at the beginning, pair programming can be extremely tiring. This is because we are doing activities that we aren't used to doing such as explaining every step, thinking about options, trying to explain alternative options, and more. Additionally, besides being tiring, pair programming is also very intensive. Due to these factors, I wouldn't recommend pairing for more than 1 or 2 hours per day, to begin with.

Once when you have paired for a while, and you have adjusted to how tiring it can be, you can pair for more than 1 or 2 hours per day. Maybe you can try pairing for half of the day. When you become a regular pair programmer, it's natural for you to want to pair always. However, not all tasks benefit from the increased efficiency caused by pair programming. So, we must choose pairing for those tasks that involve a higher complexity of understanding, where there is a greater probability for mistakes, where there is a greater capacity for analysis, where there is high impact, and more. You can solo program the remaining tasks that are basic and where there isn't much complexity to tackle. In such situations, you would just waste the other person's time.

Should you pair daily?

I would recommend beginners to pair every couple of days. In this way, they can get used to the new practice and begin understanding the small important details of pair programming. Pairing, let's say, once every month won't bring much benefit, as you will have already forgotten what you had learned after a break of one month between the two pair programming sessions. So, that is why, for beginners, a good choice is to pair for a couple of hours every couple of days.

For regular and advanced pair programmers, how often they pair depends on their list of tasks, their product, and more. I would recommend them to pair as much they can, as long as it makes sense from a productivity point of view. However, you should also take breaks from pairing, for instance, only pairing three days out of five.

Should you pair weekly?

For a beginner, pairing weekly is not often enough. However, it's better than nothing. The problem with pairing so rarely is that it's difficult to learn how to pair well. And by the time you get to the next session, your memory of the previous session is already fuzzy. So, you need less time between the sessions in order to make it efficient and easier for you.

For regular and advanced programmers, pairing weekly, if possible, can work well. I have had periods when I was pairing a lot less because of the different projects that I had. And those projects wouldn't benefit from pair programming. So, it's fine to not pair that often, as long as you have learned and understood what pairing is and how it can help you.

Working solo versus working in a pair

Working solo has many benefits, and just because we are discussing pair programming, we don't need to minimize solo programming.

It's good to solo program when pairing doesn't bring any noticeable benefit. For example, when there is not much learning or knowledge transfer, you are working on trivial tasks, have only simple problems to solve, and more. Additionally, solo programming is easier for introverts, as they lose so much energy when pairing or being in a group.

Pairing with another person comes with the clear advantage of interactivity, learning, knowledge sharing, tackling difficult tasks easily, and even creating a lot of fun for many people.

In my head, there's no one versus the other argument but how I can effectively use each of them. My advice is to not pair day in and day out, but also not to solo program without any interaction. Both are useful methods of working for everybody, but the dosage depends on each of us. Try pairing, and find the right dose for you.

You need to decide how much you need to pair yourself, as situations may differ and there is no generic answer. Your skills, your colleague's willingness to pair, the way your organization works, the project you are working in, and the technologies you are using are just a few of the factors that will affect how much you need to pair. In any situation, it's better to try it regularly, at longer intervals, than not trying it at all.

After observing thousands of pairs working during Coderetreats, hands-on workshops, or when consulting with different organizations, I think that the first essential skill you need to have for pair programming is to communicate well. That is why, in the following section, we will explore the different communication methods you can use.

Exploring different communication methods

OK, this is pure psychology, but when we work in a team, we need to communicate well in order to achieve our common team goals. Often, I consider communication one of the most important aspects of working together. Even particular, specific, and rare skills aren't as important as good communication.

Being professional means that you can have work relations with anyone who behaves decently and be able to give feedback to and receive feedback from anyone. The same happens in a pair or in a team.

When programming in a pair, it's not the time to show our ego, brag, shame others with our knowledge, or put pressure on our partners. It is quite the opposite: it's the time to explain, wait for the information to be absorbed, explain again, and then explain again. Be patient and guide your partner in order to make them understand your point of view. This is important. I have seen so many pair programming sessions fail simply because the partners were too aggressive with one another and didn't listen to each other. Sometimes, they wanted to do the same thing, but they communicated so badly that they couldn't understand that they both wanted to achieve the same common purpose.

I am by no means an expert in psychology or communication; however, working with teams has led me to learn more and more about these topics, and I will tell you how I approach three main communication behaviors inside a team next.

Aggressive communication

Aggressive communication means that we focus on our own needs, preferences, or feelings over the needs of the people around us. Aggressiveness generates more aggressiveness. It's never a good idea to respond to aggressive communication with more aggression.

When you find yourself in an aggressive stance, try to focus on the facts and how you can reach a common ground.

Submissive communication

Submissive communication means that we focus on other people's needs at our personal expense. This way of communicating will create internal frustration, and it will make us undervalue our own goals and contributions. When you find yourself in a submissive stance, try to think about how your ideas bring value to the current conversation. State your point of view, and open your heart to others.

Assertive communication

Assertive communication sits between the other two ways of communicating that we have just mentioned. Here, you focus on your personal needs but take into account and consider the needs, preferences, and feelings of other people around you. Communicating like that feels warm and thoughtful to others.

When using assertive communication, we focus on the facts and convey our purpose and willingness to find a common ground.

Making a difference with the right words, tone, and clarity

Continuing with the topic of communication, most of the time, when two people pair with each other in a nice and productive manner, they are able to communicate well with each other.

That is why we need to approach our colleagues by using appropriate words. The words that we use have meaning, and it's important to acknowledge those meanings. Sometimes, we use words that in themselves have complex definitions. Saying "I would like to build a strategy for algorithms to decouple this low cohesion structure" shows that there is a lot of knowledge being transmitted. If your pair doesn't know the meaning of all those words, then don't use them. Instead, spend your time explaining, in detail, what you mean. Ask your partner, each time, whether they understand what you mean when you use complex words in a sentence, for example, strategy, cohesion, stub, mock, double, and more.

The tone that we use is a second communication channel alongside the words that we use. Because of that, our tone needs to be in agreement with the words we use. We might be in uncomfortable situations when pairing. I know I am almost always put in novel situations, with technologies I don't know so well and with partners that I don't know that much. Because of them, we might feel overwhelmed, stressed, or tired. All of these emotions are reflected in our tone.

From time to time, I recommend that you try and actively listen to your tone. Ask yourself the following questions:

• Is my tone in conjunction with the words am I using?
• Does my tone seem aggressive?
• How can I make my tone more appropriate to the context?

I know it's not easy to do that, and it requires a lot of practice. Moreover, it requires you to ask for a lot of feedback from your partners, colleagues, friends, and family. It can be extremely difficult to change the way you communicate through your tone of voice. My only advice here is to ask for feedback, listen to the feedback you receive, and try to improve yourself.

There is that saying by Albert Einstein that "If you can't explain it simply, you don't understand it well enough." When we pair, we need to explain a lot; most of time, when we pair, we either explain what we write, explain what we think we should do next, or discuss the impact of our decisions on the future. However you put it, you need to have a continuous flow of explanation – one that is almost as long as the pairing session itself. That is why I recommend that you try the following steps whenever you explain something to your partner:

1. Prepare before explaining your point of view.
2. Take the time to explain, and don't rush.
3. Ask for feedback at the end of your explanation: Was I clear, and do you have any questions?
4. If your explanation is longer than 5 minutes, ask for feedback every 5 minutes or so to check whether you need to come back to some explanations or whether you can go on.

We have only scratched the surface of the topic of communication methods. Improving communication is a lifelong learning experience; we always have something new to learn about ourselves and others. Calmness, brevity, good vocabulary usage, and adopting the appropriate tone sounds easy; however, once you ask for feedback from people, you will see that it's a lot more difficult than it seems. So, the best approach is to consider yourself a constant student with continual openness for feedback from your peers.

Pair programming best practices

In this section, we'll look at some of the best practices to use when doing pair programming. Most of the best practices discussed here are not related to programming but to communication and social interactions. Sometimes, when I dive into this topic, I am told that this is common sense, but bear in mind that my common sense can be different from your common sense, and radically different from someone else's common sense.

These are guidelines that we need to use. And depending on each person's experience and background, some are part of their usual behavior, while some aren't. All of this behavior is either taught or self-taught, and we always have a bit more to learn and polish in order to improve ourselves.

Taking notes while pair programming

You can use a notebook, index cards, sticky notes, a piece of paper, a tablet, or even a second computer to take notes. It's important not to break the current flow when you observe something that needs to be repaired, or improved, or just something interesting that you would like to highlight.

Typically, the navigator takes notes because the driver is busy with the small details, and it would be more difficult for them to take notes. However, with experienced pair programmers, you will often have a situation where both partners will take notes.

After a while, the two partners need to start discussing their notes – including each item – and then deciding what to do next. It's important to do this every 1 or 2 hours at least, if not more often. It depends, of course, on the current course of action, and stopping in the middle of something to discuss your notes is not a good option.

Note-taking is also important because it fixes some ideas or concepts in your head. It's a proven fact that writing something down will make you remember it more easily, sooner, and more quickly. So, particularly when you are learning something new in pair programming, a notebook should be a not-to-miss item in front of you.

Starting with some small talk

Usually, I like starting with a small chat to ask my partner how they are, how they feel, what they have done so far, and more. It's always a good idea to start with some small talk for a few minutes in order to smoothly transition into the serious order of business that will follow.

During these minutes, you might find about your partner's disposition. In this way, you discover whether it's a good idea to be more incisive or more relaxed and whether it's a good idea to take on difficult tasks or simpler tasks.

Small talk is very different in various cultures, so use it as you see fit in your culture. Nevertheless, I have found it useful to use small talk to get a head start in any culture; it's just that the details and the duration were different.

Emptying your cup

In order to be able to learn something new, you need to have the openness to realize that you don't know everything. It becomes difficult, especially for senior programmers, to understand that they can learn many things even from junior programmers. Learning is our job as knowledge workers, and we need to learn from anyone who can teach something useful to us.

There is a story that comes from an ancient Asian tale about a student who was reluctant to learn and a master who explained how important openness is:

[..] Finally, the master poured a full serving of tea into his own cup, and into the cup of the student. Then he told the student he wanted to give to him some of the tea from his own cup. He began pouring tea from his cup into the student's cup, but the student's cup was already full, and all the tea from the master's cup spilled out over the cup onto the surface below.

The student said, "Master, you can't pour anything into my cup until I empty it to make room for what you are trying to give me." And the master replied, "Yes I know. And I can't give you any new thoughts or ideas or perspectives on life's lessons until you clear out some thoughts that are already teeming in your mind to make room for what I have to teach you." Then the master paused for a brief moment, meeting the student's eyes with his own knowing look and calmly but sternly said: " If you truly seek understanding, then first, empty your cup!"

So, if you want to use pair programming to its full efficiency, I recommend you, first, empty your cup, and then start pairing.

Debriefing

Perhaps it comes as a cliché, but we do need to talk about feedback.

Feedback is very important when working collaboratively in a team. It's even more important when pair programming. In this scenario, you are working very closely with someone, and it's a good opportunity to praise their good knowledge and behavior and, at the same time, to come with improvement suggestions for their flaws.

The best approach is to create a moment of openness for the pair, usually at the end of the pair programming session, where you debrief them about what happened. Each of the programmers will think about the following:

• What I liked about this session
• What I would improve

You get to discuss each one of the items presented by your pair. Then, after this debrief, it's a good idea to make a list of future actions. These can be very small actions such as starting earlier or using a different chair. Alternatively, they can be more substantial actions such as explaining more when driving, making a few design diagrams on paper before coding, and more.

Don't get personal; try to think about situations and approaches to that particular situation. Try to understand whether the approaches of both persons from the pair were appropriate, given the context.

Be careful not to fall into the blame game, believing that only the other person was responsible for any mishaps during your pairing session. You were there too, and you were both in that situation together.

Another very important note is that feedback is given for the future, and there is no need to blame someone by looking at the past. You cannot change the past, but we all can learn from it. So, consider finding lessons that you learned in the past for the future.

Dialogue courtesy

In a good conversation, listening is more important than speaking. Listening actively to what your pair is saying is very important for efficient collaboration. If you feel something is unclear, ask clarification questions such as "What do you mean by that?", "Could you please elaborate on this topic?", "I'm sorry, but I didn't understand why we need to do this," or "Could we discuss this some more?" After a series of clarification questions, you will feel as though you know a lot more about what your partner is saying, and it's a good moment to form an opinion. Far too often, I see opinions arising before clarifying a topic. And then we stop having a dialogue, and we start having a pointlessly heated discussion.

Before starting to speak, try to think about what you are going to say and how to express your thoughts. Sometimes, I take notes on a piece of paper with the main points I want to express. I try to think about how to frame my thoughts. Only after that, I wait for a good moment to broach the subject. After expressing my point of view, I ask my partner, "Was I clear enough?" or "Do you have any questions?"

Having this dialogue courtesy helps a lot to clarify topics, and it decreases the probability of starting a sterile argument. It's a good practice in almost all collaboration contexts within a team.

Building confidence – committing often and having good unit tests

When writing a big chunk of code at once, our brain cannot process all the information that we put in there, and things start becoming fuzzy. This is a great opportunity for a mistake to sneak in. We can cheat our brains by taking smaller steps because when we finish a small part and commit it, our brains relax and put that information into a drawer.

That's why there's the question, "How often should we commit?" My answer is as often as you can. I tend to commit locally in systems such as Git or Mercurial once every 5 to 15 minutes. Once you are able to commit often, you can really get into a flow. You will feel less tired and more aware of your progress.

Unit tests are among the fastest mode of quality feedback cycle for you. Use it as much as possible, and run your tests as often as possible. One unit test should run between 1 and 10 milliseconds. That means you should be able to run between 100 and, 1000 unit tests and not get bored while waiting. You can also have tens of thousands or millions of unit tests, but then you need to group them on modules, and then run only the unit tests that affect the module that you are working on.

Having unit tests and committing often is a great opportunity for a special type of dialogue for a pair. You can come up with an atomic item of work (which are a lot smaller than ordinary tasks) together with your pair, write tests for it, commit it, and then see how you made 1% progress.

Trusting your pair

You know that trust is easy to lose and hard to win. This is also true for pair programming. However, start by trusting your partner and then focus on improving anything with feedback.

Trust is very important when we pair. Far too often, programmers join a session full of suspicion and are waiting for a small thing to go wrong, just so that they can say that it doesn't work. Start by having some trust, then try pairing, then try a bit more, and then decide. Find where pairing is useful and when it's not for you in your context, for your product, and with your team.

Pair programming has a lot to do with trust, as we consider the code we write a part of our intimate work. Letting someone in can feel intrusive, and that is why all the best practices we just discussed can make a huge difference to our success in pair programming. We deal with people, and social skills, interesting dialogues, and a positive state of mind are factors that always increase the trust in your pair. We'll next look at things you should not do when you are pair programming.

Pair programming anti-patterns

Particularly during your first interactions, pair programming can seem weird and potentially confrontational. I have seen so many people who have never paired before enter and argue, and their conversations turn impolite. You don't want that to happen when you are pairing. All your willingness to try something difficult vanishes and your energy gets funneled toward a sterile discussion.

In this section, we will discuss things that I wouldn't recommend doing when pair programming. This is because they are annoying, create frustration, and can even cause anger. Be careful when you are that person doing the things we are about to discuss, and try to correct yourself. Or, when you observe someone doing these things, give them some feedback on how to improve, but treat the matter with care and empathy.

Managing distractions

We can be faced with so many distractions when pairing: our phone, our tablet, a chat, an email, a colleague's joke, and more. When you are distracted, you are not pairing. Your partner will probably feel as though they are solo programming but with a person who gets involved from time to time and doesn't really help.

Try to remove all distractions for the duration of the pairing session. Of course, you can take an urgent phone call, as nobody should be bothered by that. However, anything more than that is a distraction, and it can hamper your understanding of what your partner is doing. Additionally, it makes your partner lack the natural support of pair programming.

Centering the monitor

Very often, I notice partners starting work on a laptop, and the owner of the laptop carefully sets the monitor in front of them, while the pair struggles to look at the screen with a twisted neck. For the navigator, it feels like they are less important than the driver. The navigator cannot have the full view of the monitor, and so, cannot fully help when needed.

Try to remember to center your monitor, even a small laptop, when starting to pair. Ask your navigator before starting, "Is the monitor good for you, or do you want me to adjust it?", and then only if all is good, start pairing.

Dealing with the "I know it all" attitude

From a personal, untested statistic, 70% of people think they are better than the average. That idea boosts their ego. So, if you are one of those people, then you might think you know it all, and your partner cannot teach you anything. Usually, this attitude, which happens more often than you think with beginner pair programmers, is highly detrimental to the overall feeling of pair programming. It's not easy to start with an open heart, and then one of the pair starts dictating that this is exactly the solution, that is exactly what we need to do, without having any flexibility. The other person will either start getting annoyed and argue, or they might feel they are being bullied by their partner.

Try to ask for feedback at the end of each session. You might find that you were the person mentioned in the previous paragraph without even knowing it. Be open to suggestions, even if you know how hard it is to take feedback on how to improve, or even to take criticism. But remember that it's hard for all of us; we are all humans.

Addressing small pickings

You try thinking about the big picture, how to solve a particular problem, what the architecture is, what the design is, and suddenly your partner asks you if you should use tabs or spaces. Or why you use the mouse. Or that the color of the background is too yellowish. Essentially, they ask about anything that's marginal to the problem at hand. The details of working together are important. However, if we focus too much on small intricate details, we might not get anything done. And everyone has their own preferences.

Try to respect the other person's preferences when it comes to small details, and just focus on the important aspects of getting them done. Focus on the task at hand, and if you see something getting in the way, then address it. However, if that annoyance is not getting in the way of solving the current task, then please ignore it, even if it might be difficult for you as well.

These are a few of the typical pair programming anti-patterns that I have observed over the years. Try not to linger too much on any of these approaches. On the other hand, if you deal with people who do use these approaches, try to exercise patience since almost everything can be solved with some kind of feedback on how to improve.

Boosting productivity with remote pair programming

All of the techniques, styles, and practices that we have discussed in this chapter can also be used when working remotely. However, you do need some tools to enable remote pair programming, and we will focus on that during later chapters in the book.

Remote pair programming is wonderful because you can pair with people who are far away, in different countries, and on different continents. You can learn so much, and it is a lot easier than traveling to a conference or a workshop. You just have to open your computer, set up a few tools, and start pairing with someone who is sitting far away. You can also produce much better software if you pair for a shorter or longer period with someone who can help you in that particular situation.

The possibilities of remote pairing are endless. Your teammates can be everywhere. You can think about your usual team of 4 to 8 people, but you can also think about asking for punctual remote pairing sessions with people who aren't in your usual team. Maybe this could include people in your organization, but who are in separate city offices, and who could help you with that task. Alternatively, consider pairing with external consultants, technical coaches, or trainers to guide you when you feel you need a boost of energy, knowledge, or confidence.

Remote pairing is great, but it can somehow be more difficult than face-to-face pairing. Nevertheless, by following the preceding advice, with some practice and a commitment to openness, any challenge of remote pair programming can be overcome. You just need to try it, experience it, hang in there for a while, and it will be extremely rewarding for you and your team.

Summary

Pair programming is beautiful and pleasant, as long as it works well. In this chapter, we introduced pair programming techniques that are useful for different contexts. We need to adapt to the context in order to optimize the usage of pair programming. There is no one-size-fits-all approach because the situations where pair programming is used are so diverse.

Spicing the pair programming techniques with styles adds even more efficiency, but it also smoothens the rough edges of pair programming, making it even more agreeable. With pair programming styles, in the same way as pair programming techniques, there are variations and certain situations where each one should be used. The level of experience of the programmers involved in pairing is essential to pick the right flavor and the right spice of pair programming.

Additionally, to make things even better, we need to remember that we are dealing with people, and the way we communicate with each other is very important. Using an appropriate communication method for the context at hand massively improves the chances of a good pairing session, and it can lead to a boost in productivity. What is worse, you will want some more; it's addictive.

So, use pair programming techniques and styles, giving proper attention to details, communicate well, debrief often, and ask for feedback for constant improvement.

In the next chapter, we will get technical. We will explore which tools to use and how to use them in order to start building an efficient remote pair programming team.

Further reading

• The Elastic Pair Programming codecast from Adrian Bolboacă: https://blog.adrianbolboaca.ro/2018/03/remotepairprogramming-ep-009-adi-ferdinando-elastic-pair-programming
• Overcoming Imposter Syndrome by Gill Corkindale: https://hbr.org/2008/05/overcoming-imposter-syndrome
• Empty Your Cup: http://wiki.c2.com/?EmptyYourCup
• Quiet: The Power of Introverts in a World That Can't Stop Talking by Susan Cain: https://www.goodreads.com/book/show/8520610-quiet