Within the methodological framework of "Extreme Programming", one of the most widely used tools is "Pair Programming".

Although its name suggests that it is simply two people programming together, this practice goes beyond that. What we aim for is peer validation of the code being developed. To achieve this, we seek to share and bounce ideas off the person accompanying us in the session.

Making technical decisions between two people has certain positive implications for development teams, such as:

• Distributed knowledge.
• Reduced sense of ownership or authorship.
• A more excellent, consensus-based solution.
• Strengthened personal bonds and team spirit.
• Faster team growth in terms of knowledge and experience.
• Time investment is quickly recovered, as less time is spent fixing errors since fewer are introduced.

There are different variations of how or when to do "pairing", so the experience of working in pairs is very personal and will depend on the individuals forming the pair.

⚠️ When both individuals are new to this technique and in the absence of a mediator, it can be challenging to find synergy, even becoming frustrating. It may be advisable to start this type of practice in sessions where a facilitator is present, such as in "Mob Programming".

The roles

In a pairing session, there are two well-defined roles: the "Driver" and the "Navigator". However, how each behaves will depend on the pair and the agreements they reach. Below, I will share a personal perspective on how this has worked for me over the years and how I best enjoy this experience.

• Driver: This is the person responsible for controlling the keyboard. The "Driver" is tasked with translating the decisions previously agreed upon by the pair into code. However, the way this is executed is personal. While writing the code, the "Driver" should communicate to the "Navigator" what they are trying to achieve with the code, helping the observer understand the thoughts being translated. This will greatly help the "Driver" enter a flow state. The "Driver" should seek validation for what they are doing and be able to discuss it with the "Navigator" when deemed appropriate.

• Navigator: This is the person responsible for observing and taking notes. The "Navigator" must understand at all times what the "Driver" is trying to achieve and note anything they disagree with, find noteworthy, or feel uneasy about, including possible improvements. This information should be shared before the "Driver" takes the keyboard and after the "Driver" releases it, aiming to maintain the flow state as much as possible. There will be times when the "Navigator" needs to interrupt to help the "Driver" overcome obstacles, refocus the session when it drifts, or bounce ideas they believe are critical. The person in this role tends to lose focus, so good communication with the "Driver" is required to help keep the session dynamic.

Roles can rotate at any time, but this should be agreed upon by the pair, for example, switching roles during 50-10 pomodoros or using ping-pong TDD. The latter works quite well when the "Navigator" struggles to maintain focus.

💡 In Ping-Pong TDD, roles rotate such that one person writes the test, leaves it failing, and passes the keyboard to their partner. The person taking the "Driver" role implements the code needed to make the test pass, writes the next test, and then becomes the "Navigator" again. It is important for the tests to have high granularity for the experience to be positive.

The time factor

A common question is "How much time should I spend "pairing" each day?" The truth is that this is a very personal answer and will depend on multiple factors, more human than technical.

It is important to understand that this is a very human aspect. There will be days when, for personal reasons, it is not even advisable to do "pairing", because your state does not allow it that day, and instead of fostering a collaborative and growth-oriented environment, friction will be created.

On the other hand, constant rejection of this practice is not positive for those who do enjoy it. This is not just about personal satisfaction but also about the feeling of optimal job performance.

What is undeniable is that it is a highly demanding practice that requires a lot of discipline, concentration, and soft skills, so maintaining these sessions for 8-hour workdays can be exhausting and counterproductive in some cases.

Personally, I think it should happen naturally. Some people enjoy long and intense debates for hours, while others feel more comfortable with brevity and certainty in the points to be discussed. I have had 8-hour sessions for days that I particularly enjoyed, as well as 2-hour sessions that I wished would end.

Another factor to consider is the workload or responsibilities of the people in the session. While some people dedicate their time fully to development, others must balance it with responding to messages, providing support, or simply have personal schedules that require them to be absent at certain times. Therefore, it is best to agree on the time distribution in pairs, reach consensus, and iterate over time based on each other's needs.

What is essential is that the time we dedicate to "pairing" must be exclusive to it, out of respect for both the work and the other person.

The space

The practice of "Pair Programming" was born when remote work was not yet widespread, so it is something that has had to be redefined over time.

To understand the current context, it is important to know its beginnings and the reasons behind them. Initially, the idea was for two people to work in front of the same screen, with the same keyboard, meaning only one person could type at a time. An important detail was the choice of equipment. Both people had to feel comfortable with that keyboard and be familiar with the operating system and tools being used. Choosing a device that one of the two people is not comfortable with could affect their ability to enter a flow state.

During these sessions, the goal was to create a relaxed debate environment where code was reflected upon, and possible solutions were proposed. For this reason, having relaxing music or coffee was not uncommon. To ensure the conversation flows naturally, it is important to minimize ambient noise and ensure the conversation does not disturb other team members working in the same room.

If we bring these ideas to a remote environment, we can see how some barriers are no longer relevant, such as the choice of keyboard or operating system, as each person works with their own equipment. However, this can complicate other aspects, such as the "Driver" writing while the "Navigator" is tempted to write in other parts of the project simultaneously. While the intention is clearly to help, this distorts the practice and can become counterproductive.

On the other hand, the workspace differs slightly but is not exempt from considerations. The choice of communication equipment becomes crucial. Using a microphone that transmits clear voice and eliminates possible noise, being able to see the other person's face and interpret their facial reactions (both positive and negative), facilitates communication and significantly improves the experience.

We must consider that when we communicate in writing, only 25% of the intended information is transmitted. When we do so via call, factors such as rhythm and tone of the message are added, transmitting about 50% of the intended information (this is known as paraverbal communication). In a video call, the information is complemented by body posture and hand movements, allowing us to transmit almost 75% of the message accurately (non-verbal communication).

“The verbal component is 35%, and more than 65% is non-verbal communication” - Albert Mehrabian

The attitude

When doing "Pair Programming", it is inevitable that one of the two parties will feel more exposed than the other. This is because people feel evaluated, fear making mistakes, or struggle to clearly convey the ideas they have in mind. For this reason, many people reject this practice, preferring to stay in their comfort zone.

To mitigate this situation, it is very important to create a safe space between the individuals. Communication is key for this; we must be assertive and empathize with the people we work with. Facilitating a relaxed environment where people feel free to share their ideas is crucial, and this is precisely the benefit of this practice. If one person cannot communicate their ideas, we are missing the opportunity.

On the other hand, understanding that mistakes are positive is crucial. No one should be or feel judged for a mistake. In fact, this is the ideal space to make mistakes. Learning in confidence and preventing errors during the development phase is one of the virtues of this type of practice.

Therefore, we can conclude that people engaging in this practice must have a positive, understanding, and empathetic attitude toward each other.

Rotations

In addition to rotating between the roles of "Driver" and "Navigator", it is important for pair members to rotate with other people for several reasons:

• Knowledge is not confined to just those two people but is extended to the entire team. When people rotate and find themselves in the middle of a task, one of the two must stay while the new person receives context about what was being done.
• Attachment to the code is lost (but not to quality). The code transitions from being individually or pair-owned to a global team scope, distributing responsibility among all members.
• Frictions are minimized. When two people do not get along personally, the thought of spending long periods working together can be frustrating. Having rotations every 2-3 days allows personal relationships to avoid stagnation and instead be worked on iteratively.

What it is not

So far, we have described many of the characteristics that represent "Pair Programming", the benefits it brings, and some techniques. We might think it is a solution to many of our problems, and it certainly is, although it is not a Swiss Army knife.

We must understand that there are scenarios where this way of working does not fit or where its performance does not meet the needs of the work. Therefore, we must consider certain aspects:

• Doing "pairing" is not a Dogma. Although we have provided guidelines on how to do it correctly, there is a significant personal human factor that will determine small details about how we perform this task. This practice should be flexible and will never be the same, as it depends on the relationship between the individuals involved.
• Doing "pairing" does not mean going faster. We aim to validate ideas and be reflective, so speed in generating code is not something we will achieve. However, over the life of a product, development times are reduced because joint decisions lead to greater team knowledge, fewer bugs, and generally better design that allows for scaling. In short, we will spend less time fixing code than if people worked individually.
• Doing "pairing" is not "mentoring". It might seem sensible to consider mentoring someone while writing code together, but there is a detail that distorts the main objective: "If you are mentoring someone, you are not bouncing your ideas but transmitting them unidirectionally". Therefore, even if two people share the same keyboard, it cannot be said that this way of working is being applied.

Variants

There are other modalities, such as "Mob Programming" or "Ensemble Programming", in which the number of participants increases, causing certain points mentioned to vary, such as roles, introducing others, session duration, or even enhancing certain benefits mentioned earlier. All of this will also depend on how these sessions are facilitated.

Questions about:

AI

Nowadays, there are tools like Copilot that allow us to program and discuss code solutions as if it were our "Navigator". However, we must be aware that for this conversation to occur at the same level as with a person, we must know how to use the tool properly, providing it with team agreements, product context, particularities, etc., which is not an easy task.

Even the writing of the "Prompt" we provide to such a tool is something that can be contrasted with the "Navigator", so I believe that using these tools does not have to exclude these ways of working.

The use of Pull Requests

Many teams consider the use of Pull Requests (PR) completely unnecessary when practicing "Pair Programming" since their purpose is for others to review and validate the developed code before merging it with another branch. Seen this way, this review is already happening when working in pairs, so it is not unreasonable to reduce these bottlenecks and optimize work.

However, this view is quite simplistic, as we lose sight of the team's context where these practices are adopted. How much time do PRs spend in review? What is the team's level of experience? How much context about the development do we want to have? We should not assume that the code has already been reviewed without more. There will be situations where PRs make more sense than others, so it is the responsibility of each team to define these agreements.

Practicing Pair Programming as a junior

We might think that having little experience makes you unsuitable for bouncing ideas or validating those of someone with more years of experience. Nothing could be further from the truth. The truth is that years of experience are just a number. Ideas, innovation, the desire to improve, and the perspective of ignorance are crucial factors in development.

When someone has been doing something for a long time, it is normal to adopt bad habits or fall into automatisms, as if it were a production line. Being able to contrast these ideas with others will help the more experienced person break these dynamics that are counterproductive for development and will allow you, as someone with less experience, to benefit from all of it.

Conclusion

"Pair Programming" is a development practice that allows us to work with code by sharing ideas and supporting decision-making in a consensual way, which brings robustness and excellence to the code.

This practice is not a dogma, and given the human factor, performance will vary slightly depending on the individuals. The objective of this practice should not be lost sight of to avoid distorting it.

Sometimes, this exercise can go beyond code, even writing emails together, drafting documentation, or creating diagrams. It is very easy to enter these types of dynamics when people create good synergies, and they are not counterproductive at all.