Easy Guide to Remote Pair Programming

Remote pair programming can be an extraordinary experience that generates dependency. However, if remote pair programming is implemented poorly, it can be a hurdle and a massive pain for the team(s) and for the organization overall. But what is remote pair programming? Two people work together on the same code, on the same task, at a distance. It is that simple, but in fact it can become rather complicated.

Practical questions to ask before pair programming

Remote pair programming is possible, useful, and should be used as any other tool we have in programming: where it’s appropriate. This doesn’t mean we need to use it forcibly, when people don’t find it useful. At its best, pair programming and remote pair programming are best done when it’s wanted by the team(s), as a solution that comes from bottom up. The team needs all the support of the organization, and that can mean many things. When pairing in the office, all the access rights for the code base and all the security requirements are already in place. However, when pairing remote, you need a lot more setup and more tooling in place, so that the two team members can work together effectively.

In March 2021 I published a book called Practical Remote Pair programming with Packt, where I gathered some knowledge about how to use this practice, how to start implementing it, and when not to use it. In the following article you will see a distilled form of the book.

Practical questions to ask before remote pairing:

• Why do we need to start using remote pair programming?
• How will remote pair programming help?
• What are the advantages of remote pair programming in our context?
• What are the disadvantages of remote pair programming in our context?
• Are we fully distributed? Do we have an office, or multiple offices?
• How will remote pair programming help for achieving business goals?
• What are the task types we should pair?
• How long should a pairing session be?
• How often should we pair?
• Should we schedule the remote pairing, or be always open to work with someone?
• What tools do we use?

This list is a guideline of the main questions you need to ask before starting to pair remotely. It’s also a good idea to have some dry run sessions in a smaller test group, because you will see the limitations of your setup, and understand if the tool choices make sense. Also, it’s important to align with the whole team after that, and get feedback on your technical setup. Don’t make an ivory tower decision, throw it away to the team(s) and that’s it.

Implementing remote pair programming

Pair programming is a form of social programming. We have other forms such as code review, ensemble programming (also known as mob programming), and so on. Social programming means that you want to learn, share, advance knowledge and continuously improve your codebase together in a team. That team works better when its main values are trust and respect for each other. Social programming starts with collective code ownership, cross functional teams and constant peer review from high to low level decisions.

Social programming also means that we need to communicate well within a team, with care and respect for each other’s perks and peculiarities. A prerequisite for good (remote) pair programming is good communication inside the team, and that usually means less personal ego, and more understanding of the common good. All this translates to a good ability to giving and receiving feedback, assertive communication, non-violent communication, good facilitation skills, and many more items on a long list.

Learning is not optional when we are dealing with knowledge work, like software development. In fact, everyone who works at a software system is a part of a system that distills raw information into an automated system that works. All this process means continuously learning about the business domain, the tools we use, and how effectively we use these tools. Alex Bolboacă says that “software is a knowledge distillery”. That means that software development has knowledge at its center, and learning is not optional.

We can surely learn individually, but when we talk about a complex system, a difficult domain, it’s a lot easier to learn together. Each one of us takes one part, and we regularly work together so we constantly align the knowledge between us. Pair programming is a great tool for aligning knowledge, for learning together in a practical, hands-on approach.

The more we learn, the more we know, and the more effective we are. Each business domain has peculiarities- some simpler, some riskier areas- and the more we go deep inside the domain, the more effective with our software solutions we can be. But learning about a business domain cannot be just a theoretical aspect; we need to roll up our sleeves and start translating our understanding of the business domain in software. The more complex the domain, the more effective social programming, and thus pair programming is. When we work individually, we all have our blind spots, and working together, the more promiscuous we are when pairing, the better. Yes, there’s a practice called promiscuous pairing that means we need to pair with everyone, especially on complex and difficult systems. Promiscuous pairing becomes even more effective when all the roles are involved: programmers, testers, business analysts, security experts, DevOps, and so on. So, pair programming is not just about programming; it’s more about knowledge work and advancing the quality of the software product.

There can be many reasons why you want to start pair programming, and sometimes the tools for remote pair programming are very different, depending on the goal we choose. So here are the typical goals:

• Align knowledge
• Introduce new knowledge (new business domain, new tools, methods)
• Add new people to an existing team
• Add an existing team to an existing product or project
• Start a new product or project
• Minimize defects
• Minimize development and testing duration
• Minimize deployment duration
• Improve user experience
• Increase team cohesion
• Eliminate silos between specializations

We didn’t touch on tooling, so now is a good time. I usually don’t want to focus on tools, as they are just a helper to make us work effectively, but in the context of remote pair programming, they are essential. You cannot use remote pair programming without at least the simplest tool: a screen sharing application. There are two types of these screen sharing applications: screen sharing as video, and screen sharing as remote desktop with which you can interact.

Pairing on remote desktop can work for a short while, but if you use it for a long time, you can see how the lags, delays, or disconnects start to be tiring and annoying. This is the reason why you probably want to use an appropriate tool that is built for remote pair programming like:

• Code Together
• Floobits
• Use Together
• Tuple
• Visual Studio Code with Live Share (which works with most programming languages)

I used all of them in different situations, and I can say that none of these tools are perfect. You need to try each one of them and see if it works for your context. Obviously, none of them is mature enough for a seamless remote pair programming experience, but with a few drawbacks it still gives you an amazing remote pair programming experience.

Some tools people tend to forget about when doing remote meetings or remote pair programming are about sound and video. You want good quality microphones (ideally a semi-professional setup, not a headset or a phone microphone), and you want a good HD quality camera, ideally a semi-professional DSLR or mirrorless camera, with a capture card.

Depending on your context:

• how often you want to pair
• your source code rules and source control
• how dissipated or structured the knowledge is in your team
• security concerns

you might need different tools for remote pair programming.

Source control is also a tool that is essential for remote pair programming. And while you do remote pair programming, the usage of source control is different. For example, do you work on a new branch, the main branch, your partner’s local branch, or your local branch? It’s important also for security reasons, as you need to make sure you don’t move or show code through tools that are not secured, especially if you work on sensitive or regulated products.

A question I receive often is: How often should we pair? The answer depends a lot on your purpose, and how mature your team is. For example, for a team made only of experienced programmers, it’s a good idea to pair a few hours per day. It will be difficult in the beginning, it will be tiring, but it can start being a good practice and the team might start enjoying it so much that they won’t want to go back.  Another example is if your team is comprised of a mix of experienced programmer and also mid-level or junior programmers. In this situation, I would focus more on leveling knowledge, distributing knowledge about the business domain and about coding techniques. If you would pair four hours daily with a junior programmer, that person will be tired after a few days, and there wouldn’t be much space for new lessons. So, pairing with less experienced programmers has a different rule, and you should discuss in the team how often to pair. You might have loner programmers who like coding alone. That is perfectly ok; nobody should be forced to pair, as long as we keep up the quality of the product, and we can distribute the knowledge in the team. So please take into account all the views of all the team members of remote pair programming and solo programming.

I am a strong promoter of continuous improvement and retrospectives, and I think we should use these principles and techniques with remote pair programming as well. My advice is to get together with the whole team every few weeks and discuss how you feel about your remote pair programming work. Think about more than tools. Try to get into how you communicate, how often you commit, what you could learn more, or what you could improve. We are living in a knowledge world, and we can constantly learn new things and improve ourselves. Sometimes pairing with people from other teams is a good input for a retrospective, where team members can learn how others work, and take practices back to the team.

When pair programming doesn’t work

Until now I have presented the good parts of the remote pair programming technique. But there are also weak points that we need to take into account. There is no silver bullet, and remote pair programming is not a silver bullet either.

Solitary programmers who feel well programming alone and are efficient shouldn’t be forced to pair program. There are so many reasons why one would like to work alone, and not in a pair. We can think Think about people who are very introverted, deep experts in a difficult domain, or people who aren’t used to collaborating with other people. No practice should be forced on anyone, but rather explained, slowly introduced; we need to know and accept that some people won’t like it, and won’t use it.

Another situation when (remote) pair programming doesn’t work is when there is a strong push against collaboration in the whole organization. The management can instill these values that we need to work on individually; everyone needs to be evaluated for their own individual work as otherwise evaluation will be very difficult. There can be many situations where accountancy, evaluation and task-keeping needs to be written according to the particular rules of the organization. Pair programming won’t work in this environment.

There are also organizations where there are strong silos, and you might be able to work in a pair in your own narrow specialization, but never with other specialization. For example, Java programmers will never be allowed by the organization to pair with the JavaScript programmers, because they are from different departments. Typical concerns will arise around how to record billable hours or which manager will be responsible for the work of the two if the programmers come from two silos with two different managers. So, there can be a strong push against collaboration inside the organization, and in this context any form of ensemble programming (pair programming, mob programming, coding dojos, and so on) will not work.

It’s a good idea to introduce a new practice when the team has the time and energy to absorb new ideas, concepts, and movements of a new practice. That is why one should never introduce a new practice when they a tight delivery or development schedule, before a deadline, or when the team is learning or trying something else which is new. A new practice, a new approach, a new way of working should be implemented one at a time; otherwise the failure probability is quite high. And it may not be the fault of the practice itself, but of the timing when it was introduced.

Pair programming makes sense when a task has a certain degree of complexity, so the two programmers will be efficient together. However, there are many tasks that are simple, for which pair programming would be a waste of time. These are tasks that are boring and could be automated, but they don’t happen that of often so automation would be a good investment, or tasks where you create a simple configuration, setting up a coding environment, and so on. Every team knows which are the more complex tasks and which are the simpler tasks. In order to bring effectiveness with (remote) pair programming, the team should decide to pair only on the more complex tasks, and do solo programming on the simpler tasks. Of course, if learning is the focus, the team should decide to teach the junior programmer how to perform that simple task with pair programming, but only once or maybe twice.

Conclusion

All in all, pair programming needs to feel like time is well spent, where the team works as a whole.

Remote pair programming works great in open environments, where teams have the power and the ability to decide for themselves, where teams are left to be mature and are mature enough to discover their own tools and practices. Nevertheless, in these teams one should never be forced to pair, but rather have the option to pair. Anyone should be allowed to freely accept or deny (remote) pair programming.

Remote pair programming works great if implemented well, with regular improvements, and when the team reflects on how to make it better.

With pair programming communication is very important, but with remote pair programming quality communication is essential because we lack the physical presence that gives us so much non-verbal communication. We need to communicate better, wiser, and calmer, showing respect for each colleague.

Sometimes implementing remote pair programming works a lot faster and better when a technical coach is involved in the process, and that is valid for many of the technical practices.

About the Author

Adrian Bolboacă has over 15 years of international experience in product and software development in small and large companies, having served customers from various European countries. He is an experienced trainer; he enjoys teaching passionate people from dynamic companies to exceed their potential by challenging their current activity model for better collaboration, performance, and satisfaction. Bolboacă has trained and coached individuals and teams on both the technical and organizational sides on topics such as architecture and software design, agile and lean transformations, visual management, continuous improvement, Scrum, Kanban, unit testing, TDD, pair-programming, clean code, rescuing legacy code, and much more.