Pair programming can be a powerful practice for producing high-quality code and nurturing a collaborative development culture. However, its success hinges on nuanced behaviours and practices that can either make or break the experience. Let’s start with the good, and hopefully you have seen examples of these.

Effective Pair Programming Behaviours

Communication

Open and constant communication is the cornerstone of successful pair programming. It’s not just about saying what you’re doing but explaining the why and the how. This includes articulating your thought process clearly, asking questions, and actively seeking feedback. The goal is to always have both partners on the same page, eliminating assumptions and minimising misunderstandings. Admitting mistakes is also great for demonstrating humility of your coding skills and allow your partner to feel more at ease, especially if the pair has different levels of experience.

Role Rotation

The dual roles in pair programming—Driver and Navigator—are intended to be swapped regularly. This ensures that both participants stay engaged and contribute actively to problem-solving. Regular role rotation also prevents cognitive fatigue by allowing each programmer to shift between high-level thinking and focused coding.

Clear Goals

Effective pair programming isn’t just about coding together; it’s about achieving a shared goal. Both participants must understand the task, the requirements, and what ‘done’ looks like. This mutual understanding guides the work and provides a basis for decision-making throughout the session. Three amigos is a technique that really helps in product team settings, as not only do the pair align, but they align with the Product Owner and other team members in their understanding prior to grabbing the keyboard.

Respect

The collaborative nature of pair programming requires mutual respect. This is manifested through active listening, valuing the other’s contributions, and acknowledging the unique skills and insights that each brings to the table. A respectful atmosphere breeds constructive criticism and open dialogue. Give praise where it is deserved, you are a team and not in competition, so build each other up.

Engagement

True engagement means both participants are actively contributing. If one person is writing all the code while the other is merely watching, then the essence of pair programming is lost. Both should be fully involved in coding, problem-solving, and decision-making. If this isn’t the case then stop and review what’s going wrong so that time, effort and money are not wasted.

Comfortable Environment

A conducive coding environment is essential for effective collaboration. This means having a set-up where both participants can comfortably read the code, navigate files, and use debugging tools. The idea is to eliminate any friction that might stem from the coding environment itself. Multiple screens, keyboards and mice, and plenty of space can help a pair focus on the taks and not the logistics, and it’s a low cost thing to sort out, but very expensive if the pair don’t have what they need to deliver effectively.

Breaks

Pair programming is mentally intensive. Regular, short breaks can serve as a mental ‘reset,’ making room for fresh perspectives. These breaks are also an excellent opportunity for a quick review or to clarify thoughts. Different people work in different ways, so talk to one another and agree how you will plan in breaks so that you can find a rhythm that works for you both.

Feedback Loop

Reflecting on the experience is crucial for continuous improvement. Discuss what went well and what didn’t. This feedback loop provides actionable insights for future sessions and helps in fine-tuning the pairing dynamics, it should be similiar to a retrospective, in that you are being objective and assuming the best of your partner so that you can truly optimise and excel.

Balanced Participation

In an effective pair programming session, no one person should dominate. Both should have equal say in the coding process, from the smallest syntax decisions to high-level architectural choices. Balanced participation results in more robust solutions and greater team synergy.

Code Quality

The ultimate aim is to produce code that is clean, maintainable, and bug-free. The collaborative scrutiny in pair programming often leads to higher code quality when compared to solo programming, making it easier for you or someone else in the future, to understand and modify the code.

Now we turn our attention to the things that lead us to question the practice, and sadly too many of us have witnessed these also.

Anti-Patterns: The Traps to Avoid

Silent Treatment

A complete lack of communication defeats the purpose of pair programming. When one programmer codes in isolation, failing to articulate their thought process or seek input, it hampers collective problem-solving and reduces code quality.

Monopolising Keyboard

If one person does all the coding, they essentially hijack the process. The other person becomes a passive observer rather than an active contributor, undermining the benefits of collaborative programming.

Backseat Navigator

A Navigator who only points out mistakes without providing constructive solutions is merely a critic, not a collaborator. This creates a negative atmosphere and stifles creativity.

Overpowering

When one programmer dominates discussions and disregards the other’s suggestions, it squashes the collaborative spirit. This kind of atmosphere often leads to suboptimal solutions and can be demoralising for the less assertive participant.

Stubbornness

Pair programming requires flexibility and openness to new ideas. Being overly stubborn or sticking rigidly to one’s viewpoints can hinder progress and compromise the quality of the code.

Distractions

Checking emails, social media, or any other form of disengagement disrupts the focus and flow of pair programming. It also shows a lack of respect for the collaborative process.

Lack of Commitment

If one or both programmers are not fully committed to the task, it can result in a lack of focus and low-quality work. Half-hearted efforts can undermine the entire premise of pair programming.

Role Rigidity

Insisting on sticking to one role—either Driver or Navigator—throughout the session can lead to imbalance and fatigue. It also deprives each participant of the benefits that come with switching roles.

Mismatched Skill Levels

Extreme discrepancies in skill levels can make the experience frustrating for both parties. While some difference is beneficial for mentoring, a huge gap can make collaboration difficult.

Over-Extended Sessions

While pair programming can be intense and productive, very long sessions without breaks can lead to mental fatigue. This can compromise decision-making, creativity, and ultimately the quality of code.

To wrap up…

Pair programming is as much about human interaction as it is about coding. Effective practices like open communication, role rotation, and balanced participation can elevate the experience to more than just the sum of its parts. Conversely, falling into the traps of the common anti-patterns can make pair programming a draining and unproductive endeavour. Being aware of these effective behaviours and pitfalls is the first step toward mastering the art of pair programming.