In this article, I'd like to talk about pair programming for remote teams as a practice.

I recently finished reading the book From Chaos to Successful Distributed Agile Teams, which is about how distributed agile teams, across multiple timezones, still can collaborate to deliver and be agile. It inspired me to write this.

If your team is working across multiple time zones, it is important to find some time when the team members' time overlap, otherwise pair programming will be very hard to do.

A Practice

Sometimes it can be seen as if pair programming is something very hard to do remotely. I've also noticed it rarely gets applied as a practice (besides following tech, I've interviewed with over 50 companies beginning of this year). By practice, I mean the definition Extreme Programming introduces, something that is done daily. Not once a week, twice a week, or a few times a month, but daily.

What is pair programming?

Pair programming to me means two developers getting together and working on something together. Most of the time one is the driver and the other passenger, meaning one is typing on the keyboard and the other one is sort of behind them as a reinforcement or watcher you could say.

Remotely, this is often two developers hopping on a Zoom or Slack call, or something similar, and the driver would share his screen, and they'd work together on a specific task.

You might think of pair programming when you're stuck and ask your teammate for help, then they help you and hop off the call once they've helped you become unblocked. To me personally, that isn't really pair programming, that is helping your teammate who is stuck, and helping overcome the hurdle. The intention of the person helping isn't to pair code, to work with you on the task, it is to help you get unblocked.

You might disagree on the point here, which is completely fine, I know some who do, and I respect their opinion.

The benefits

Let's talk about the benefits of pair programming as a practice. This is taking into account that is done daily for an amount and that the pairing partner is being rotated, so one isn't working with the same person every single day.

Real-time feedback

When working with another person, as a driver, you will get real-time feedback on the code you write. You will be able to discuss the implementation with your pairing partner and be able to exchange ideas in real time. This could also lead to new ideas being brought up, of better ways of implementing something or improving the user experience.

Real-time feedback and discussion are extremely valuable and far different from when working solo.

It leads to increased quality, in both the code and approach to the problem.

Skip code reviews

You get to move faster since the async code reviews can be skipped. Async code reviews can be quite time-consuming, especially when there is a back-and-forth happening, i.e. when the reviewer asks questions to the author.

Increased bus factor

By rotating pairs and coding with everyone on the team, the bus factor will be increased. Everyone will learn from everyone and work on different parts of the system, not just a specific part.

This will lead to the software lasting longer (increased lifespan) and if someone is sick or gone, the team isn't dependent on that person in order to be able to move at a solid pace.

Many times in teams you've one or two who you are very dependent on for certain things, and if they're gone, it will lead to the pace of shipping slowing down, because teammates need to take time to get familiar with the particular part of the system.

Bringing up the bus factor and thinking this way on a team, wanting to move at a solid pace even if one or two aren't here anymore, will hopefully shift the team's mentality to collaborating more as well as taking ownership and striving to learn about all parts of the codebase the team is responsible for.

Teamwork and atmosphere

By making sure everyone works with everyone on the team:

• Discussing
• Giving feedback to each other
• Building trust
• Collaborating

The teamwork first and foremost will be improved. Teamwork as with anything else, to do well, takes practice and time. You need to work with your teammates. Especially once you learn how to work with different people & adjusting depending on the person since everyone is different.

This will also lead to a better team atmosphere. The teammates' focus shifts from individual work to teamwork. They start thinking more in Flow Efficiency: The output of the team instead of the output individually.

The below image is taken from the book From Chaos to Successful Distributed Agile Teams:

Implementing it

Implementing pair programming as a practice remotely is hard. It sounds fantastic, but getting your team to collaborate more than they already are, is difficult.

I don't think forcing your teammates to do something will lead to any good, even if it is positively meant, they will likely not perceive it as something positive.

If you want your team to collaborate more, you need to lead by example, encourage it, and speak highly of it.

As an engineering manager: You can encourage collaboration and reward those who do collaborate. Tell them how nice you think it was seeing them pair and collaborate, mentioning in public the benefits of pair programming and why you think it is great. You can ask several of your engineers if you could pair code with them, scheduling a time and working on something specific, and telling them you're looking forward to it. Be positive, and lead as a practical example.

As an engineer: You can ask other engineers on your team if you could pair code with them. Be positive, tell them you're looking forward to it, learning from them, and that you appreciate it. Once you've pair coded with someone, tell the team openly how it went, why you liked it, and hope to do more of it. Showing passion and love for something can make others curious and want to try it, or learn more about it. It again goes back to leading by example, by doing it yourself, and not forcing others or pushing them to.

Don't turn pair programming into something that is forced within the team, rather turn it into something members on the team not just want to do, but encourage each other to do as well.

Forcing never leads to a good atmosphere, but what do:

• Positivity
• Healthy discussions
• Respect (whether agreements or disagreements)
• Listening to each other
• Having empathy

Conclusion

Pair programming is great, but hard to implement as a practice. The practice should come as a consequence of encouragement and people on the team being practical examples.

It should come from free will, we want to collaborate in a good and bright atmosphere, otherwise, the collaboration will be difficult, boring and bitter.

When done right, you can move faster with increased quality, which will lead to increased customer satisfaction.