About the author
Albert Row is a senior software engineer from the San Francisco Bay Area with over 12 years of experience as an individual contributor, technical lead, architect, open-source contributor, and manager.
Albert has been a certified reviewer on PullRequest since December 2019.
This time is really hard on just about everyone. Most of us are feeling isolated, sad, scared, and really need to get our mind off things. It can be hard to motivate ourselves to work when so much of our lives have been turned upside down by the pandemic. It can be doubly hard when the work is intellectually challenging and solitary.
Luckily most of us don’t have to work alone through the pandemic! I’ve found that remote pair programming helps me get moving, stay on task, and reduces my feelings of loneliness throughout this stressful time. I’d encourage you to give it a try! Here are some recommendations on how to get started:
Schedule time for pairing
In remote organizations, it’s somewhat harder to tap someone on the shoulder and ask them to work with you on something. I’ve found some success putting in recurring meetings for my team to pair. Right now we’re doing an hour a week of scheduled pairing, and I’m thinking about increasing that amount of time, given how productive the sessions are.
At the beginning of the meeting, we all hop on Zoom and people state what tasks they have available that would benefit from pairing. Other engineers raise their hands to help, then we jump into breakout rooms in pairs. From there, it’s up to each pair to decide what tools to use.
Find tools that work for your team
We find that Visual Studio’s Live Code feature is awesome for a lot of pairing. It allows shared terminals, editor windows, and even shared servers to allow you to collaborate on a web project. In the past, with other teams, I’ve gotten a lot of mileage out of shared pairing EC2 instances with Vim and TMux pre-installed. In previous remote roles, most of my pairing was with one or two other engineers, so working this way made a lot of sense - we could get used to each others’ VIM bindings and we were all comfortable in command-line-based development.
There are many other good tools out there, it’s worth looking into what might work for you. Even with strict security requirements, there are plenty of great services out there to make it work.
Use a different tool for video/audio and editor sharing
In my experience, the stand-alone video and audio chat platforms do a much better job at, well, video and audio chat than the tools that are responsible for video, audio, and code sharing. I think going with Zoom or Google Meet alongside one of the previously mentioned editor sharing tools is a good decision.
It doesn’t matter how good the code-sharing experience is if you can’t talk with the person you’re pairing with.
Share strategies to help your team
There are a number of good strategies for pairing. One of my favorites is for one developer to write the test, then the second to write the implementation. This can be really great for teaching less-senior developers about Test Driven Development (TDD), and also creates good moments to switch “drivers” on the session. Another interesting plan can be to set a 5-minute timer, and change drivers after the timer goes off.
It’s important to make sure that both people are participating and that you haven’t fallen into a programmer/observer pattern for too long each session. Both people will learn the most and enjoy the session the most when they actively participate. It can also be good to change partners between pairing sessions. Try to make sure that you don’t have the same people pairing together each time.
This will help knowledge move around the team and strengthen relationships between people who might not naturally work together.
Give yourself time
Pairing remotely takes some getting used to, especially for folks who haven’t had much experience working remotely before the pandemic. The rhythm of communication over a call is different than the rhythm in real life, and having a shared cursor with two keyboards can take a little getting used to if it’s your first experience doing it. I can reassure you from long experience that remote pairing can be as productive or more productive than in-person pairing for many software developers.
Stick with it and iterate on your approach until you find something that works for you and your team.
Take appropriate breaks
100% pairing in a remote environment is often more exhausting than 100% pairing in-person. “Zoom Fatigue” is a real thing. Being on a video call all the time is very tiring and it’s best not to wear everyone out by pairing for too long at a stretch, or for too many hours of the week. Your tolerance will probably vary with how many other meetings you’re required to attend, how comfortable you are on camera, and to what degree you enjoy pairing with other engineers.
Gather feedback after pairing sessions and adjust length and frequency until your team is reasonably happy with the results. Keep in mind that different people will have different tolerances, and it’s OK for participation to vary amongst the team. Remember that time spent pairing should reduce team stress, not increase it.
Try to have fun with it!
Working together on difficult problems should help the team enter the flow state - and that should be fun! If you’re not experiencing that, iterate on your process, or tweak the timing and duration of your pairing sessions. Again, make sure that the pairing experience is as positive as possible for everyone involved.
There’s more than enough stress in 2020 to go around already, and pairing on hard problems should be fun for the Software Engineers you work with. Make sure to keep an eye on how everyone is reacting to pairing, and don’t “force” parts of your process if they’re not going well. Give everyone some time away and try again later with a different approach. Above all, laugh at your mistakes! We are not perfect, and sometimes hilarious failures come up during pair programming. That’s my favorite part.
Also be sure to check out:
