Tips for Remote Pair Programming
Pair programming is a great practice, but what happens when half your engineering team is in another country with a different time zone?
Over the years, I have found that when it comes to remote working with your team (and especially with pair programming), behavioural changes rather than technical changes are more effective in making a change to the session.
I’ve been part of a distributed team for two years where we work together with a 2–3 hour time difference and pair programming as a strong agile technique within our team. Now that many of our work processes have shifted online due to the COVID pandemic, here are some of the things I’ve found to be most important when pair programming remotely.
What is pair programming?
Pair programming is the practice of working on lines of code on the same computer with a fellow developer. Within the practice there’s a driver and a navigator. The driver modifies the code, while the navigator observes and suggests which code to implement, including spotting any mistakes. To get an optimal solution it’s best to switch the driver and navigator roles on a regular basis.
It’s a fantastic way to collaborate and it promotes teamwork and knowledge sharing within the team. Pair programming often leads to higher quality code and fewer bugs as you’ve got a navigator who’s reviewing code as you program and also someone else brainstorming implementation of code with you.
Remote pair programming is similar to pair programming, however, it is done remotely using two computers rather than one. Given the remote nature of the setup, you’re no longer physically sharing the same desk and computer. Instead, you rely on sharing tools and communication technologies to achieve what’s usually done in person.
Setting up the remote pair programming session
Before we dive into pair programming remotely, what tools do we need to get started? Below are some key tips I’ve learned when setting up pair programming sessions over the years:
A good wifi connection
This is important for connecting together! A good wifi connection helps to facilitate all the other technologies we need for communication and code sharing. I’ve had some pair programming sessions in the past where the connection was unstable. A tip is to turn off the camera and switch to just a voice call — this helps with the lag when sharing your screen.
Code Sharing tools
There are some collaborative code editors out there that facilitate sharing of code with your peers (e.g. Visual Studio Code). This is great as it gives us the ability to co-edit, co-debug and share a server! Nevertheless, the downside is there can often be a lag when sharing the remote coding space with someone else and this can hinder the coding experience.
Alternatively the driver of the pair can share their screen with the navigator allowing both users to see the code. Some screen sharing tools include Zoom, Team Viewer (Microsoft teams) and Google hangouts. A cool functionality that Zoom has is the ability to control a remote computer where you give control to participants.
A good communication medium
Communication is a crucial part of pair programming so making sure you have the communication medium to facilitate this is important. Examples of software include: Slack calls, Zoom and Google hangouts.
Now that we’ve got the setup to help facilitate a good pair programming session here are some things I found useful to be aware of when pair programming — they might not be as obvious when you’re doing it in person.
When is pairing most effective?
Pair programming can be really tiring. In my opinion, it’s even more tiring when done remotely! It’s a highly social interactive process because you constantly need to be engaged, not only with the screen, but also with your partner.
I’ve had times where I’ve spent four hours on call with another developer (an hour past my usual sign off time) with no breaks in between because we were so engrossed in what we were trying to solve. Because of this, you can often experience “screen fatigue” or just fatigue in general. That’s why it’s important to set boundaries with your pairing partner and it’s even more important when you’re working across time zones. Setting up boundaries and workflow expectations ultimately help with engagement levels while pairing, making the time you spend together as efficient as possible.
Setting boundaries and expectations
You and your peer may have different styles of working so it’s important that you both understand how each person works.
Everyone has different energy levels, interactive preferences and introversive/extroversive tendencies — this is why it’s important to incorporate breaks. It could be as little as 10 mins every hour or simply calling out whenever you need a break. Regular breaks are important as they help mitigate any feelings of fatigue that you may experience.
Communicate your preferred style of video calling. It’s okay if you prefer to have your camera off during the session, just make sure that everyone is continuously engaged in the pairing.
Not everyone has the same work schedule
Communicate your availability and scheduled meetings to your pairing partner. This ensures that there is enough time for paired coding, as well as allowing the pairing session to end before any other meetings. I’ve often found that being in back-to-back meetings and pairing in between can be really tiring, so schedule the pairing session to end five to ten minutes before the next meeting to give you and your partner a much needed break.
Respect each other’s working time. This includes understanding the different working hours due to time differences or even the different working styles of your colleagues and pairing partners.
I’ve found while working with team members from Kuala Lumpur, we tend to get quite passionate about our work and sometimes forget the time difference. For example I would message team members early in the morning, which would be a couple of hours earlier for them, or work past our allocated working hours. Optimise the time you have together, but don’t forget that you need to be respectful of everyone’s working time.
Set time aside to research alone
Sometimes working individually can be just as useful as working side-by-side. I often take advantage of the two to three hours I have in the mornings, while my pairing partner is not yet online, and work by myself to do some self-study or research. You can do this even without the time difference. It’s okay to propose some time away from pairing to do some research and then come together again with what you’ve learnt. I’ve found this to be very impactful when it came time to pair as both developers brought different perspectives from their findings.
Stay focused!
It’s easy to get distracted with your own screen when pairing. I sometimes find myself, when in the navigator position, distracted by emails or slack messages.
Remember pair programming is only beneficial when there’s engagement!
This is why I make a conscious effort to minimise or close any distractions on the screen so that I can focus on the code that’s being shared by the driver. Enabling do not disturb or focus assist is also a great way to minimise the number of interruptions you receive.
The key is communication
Remote pair programming definitely comes with its challenges, but the key is communication! Tell each other your expectations and use trial and error to see what works best for the both of you — no pair is the same!
I find this practice to be a really powerful way to greatly improve your development skills and I love the knowledge sharing nature of it. Even with the constraint of being in different places and time zones, I find that I’m constantly learning something new every time I pair with different engineers on my team as we push out well thought out code.
