Lennon and McCartney. Penn and Teller. Venus and Serena.
Sarah and Rohit.
Some of the greatest achievements in history were produced by pairs of great minds working side by side on the same task. Software is no exception.
At VMware Pivotal Labs, we have long been known for being on the cutting edge of agile software development—some might even say extreme. One software development technique becoming mainstream is pair programming, whereby two programmers work on the same problem, at the same time, on the same computer, with the goal of producing amazing software quickly.
Yet at the time of this writing, COVID-19 is raging across the world. Most software development teams are now distributed, working from home. So, how do we practice pair programming in this environment?
Ironically, now is a perfect time to practice pair programming, but remotely.
What is remote pair programming?
Remote pair programming is pair programming with the help of commonly available collaboration software. While this might seem too simple an answer, pairing is pairing, whether it’s done in person or involves remote interactions. Currently, Zoom is the hero of these collaboration tools, enabling high-quality audio, video, and seamless remote control screen-sharing capabilities. But watch this space, as collaboration software changes—and improves—rapidly.
We’ll dive deeper into pairing and remote pairing later in the “Tips” section, but first I’d like to talk more about why now is the perfect time to employ remote pair programming.
Why remote pair programming now?
In addition to being an incredibly powerful software development technique, remote pairing will help you and your team become better teammates by keeping you deeply connected. Your team will also learn new tools and acquire tangible skills they can put to use in the future.
I’ve been remote pair programming full time since 2010 (and in-person pairing since 2000), and can vouch for its ability to not only help programmers build amazing software, but help them build amazing teams. As we adhere to mandatory quarantine orders, teams need all the help they can get to keep working as well as to stay cohesive and connected. Until recently, you likely relied on organic means of staying connected with colleagues, through lunches, random conversations, those brief moments before and after work when you get to know someone a little better. Organizations are now hosting a variety of virtual social events, but they don’t always do enough to address the hours of isolation that might be wearing on your development team.
So, let’s inject a bit of social interaction into your social distancing.
5 tips for effective remote pair programming while working from home
I’ve outlined below five key principles of pair programming along with how to apply those principles while remote pair programming. You will see overlap and complementary themes. Hopefully these tips will not only help your software team produce amazing results, but will also keep your team sane as we get through this COVID crisis.
1. Practicing continuous software design
All software developers should spend time intentionally thinking about the design of their software. Which architectures make sense for the problem at hand? Do common design patterns apply? Are there existing libraries and frameworks that help solve this problem?
With pair programming, you and your pair are constantly bouncing ideas off one another, adjusting the software design directions to take. I often call this a continuous negotiation, but instead of “falling to the lowest common denominator” you “rise to the best solution,” an accumulation of the best ideas harvested from your combined experiences. And if you rotate pairs on a regular basis, this continuous software design continues to evolve as the sum total of the team’s experience is put to task on the problems you are solving.
How to do it remotely: Leverage whiteboards. Many programmers collaborate on software design by grabbing a handful of Expos and whipping out some boxes and arrows. But all of our whiteboards and markers are back at the office, and there are few experiences more frustrating (and frankly, insulting) than pointing a laptop camera at your own whiteboard and asking everyone to follow along.
I recommend using one of the many online collaboration services that support boxes and arrows and virtual sticky notes. These include Miro, Whimsical, Jamboard, Diagrams.net, and many others. Yes, this is yet another tool to learn, but doing so will add tangible skills to your arsenal. As a bonus, the entire team can contribute at the same time using these apps. Try having 20 developers at the same whiteboard sometime.
2. Vocalizing your intentions
Programmers often talk about being in the zone, a mental state where the code seems to pour out of you, where the problems fall before you one by one as you knock out solutions in quick succession.
But have you ever emerged from hours (or even days) of being in the zone, gathered the team together to tell them what you’ve been doing, and realized as soon as you say the first few words that your solution absolutely will not work and is fatally flawed? I know I have. This is the trap of being in the zone—you tend to have mental blinders on.
So where does pair programming help with this problem? You have to talk about what the heck you're actually doing. We process problem-solving differently when we talk about and explain ideas than we do when we’re heads-down. Exercising those “external” verbal as well as “introspective” mental pathways helps us see the flaws in our solutions, and invites our pair to contribute.
How to do it remotely: Turn your audio and video on! Taking your collaboration to the next level can be challenging in person, and even more so remotely. With remote pairing we need every bit of high-fidelity communication we can get, as we lose a lot of subtle visual and audio cues when our collaboration is confined to a small video image. So high-quality audio and video are almost always a must. Turn your video on, and invest in a high-quality headset with a microphone, or quality external microphone and speaker, for your remote collaborations. Not only are you vocalizing your intentions, but you’re also demonstrating them visually much more that you might realize, even via a video screen.
3. Programming by not programming
Pair programming is two programmers solving the same software problem at the same time, on the same computer. But what happens when they plug two keyboards into the same computer and start pounding away at the same time? Chaos. Computers don’t work that way. Luckily, that’s the point of pairing.
While there are many pair programming styles, in my experience the most common is the driver/navigator style. At any given moment, one person is primarily coding and thinking about the next logic statement (the driver) while the other (the navigator) is looking back at what was just done, suggesting the next course of action, and strategically thinking further ahead. Our brains have extreme difficulty performing high-level strategizing and detailed execution at the same time, which is why two brains are better than one in complex problem-solving situations. Pairing addresses this conundrum by having one person for each role.
Don’t forget to switch roles! How often? As often as is needed, usually multiple times per hour. I’ve found that a natural cadence emerges out of a pairing session. The driver is on a roll, cranking out some great stuff, but suddenly stops and stumbles, having exhausted their train of thought. The navigator, who up until that point has been contributing at a “higher level,” can usually take over driving, either picking up where the former driver left off or taking a fork in the metaphorical road to explore an alternative direction they see coming. This frees the former driver (now the navigator) to think strategically, and also reflect on what they have done so far. I call this “riding the peaks.” We all have energy peaks and troughs throughout the day, even within an hour, and this driver/navigator switching flow lets us “ride the peaks” of that energy.
How to do it remotely: Use screen sharing vs. presentation software. While remote pair programming, usually (but not always) one person is hosting the session on their computer, sharing their screen with their pair across the Internet.
Notice that I said “sharing,” not “presenting.” Use software that allows both people to take control of the screen to code and use other shared tools. We want to enable seamless driver-navigator switching with remote pairing, just as two keyboards plugged into one computer supports seamless switching during in-person pairing. Clunky “request control” or “give control” handoffs add friction to the pairing flow and discourage a balanced driver-navigator dynamic.
4. Learning from others
A common complaint among programmers is that their skills are stagnating, that they’re not learning new technologies or techniques at work. The best way to learn new hands-on skills is to work closely with a peer or someone more experienced than yourself. For programmers, pair programming is unmatched as a method of upskilling, usually for both parties.
How to do it remotely: Stay engaged. When you’re remote pairing you have your own computer, complete with apps that tempt you to stop paying attention to the task at hand. And as COVID-19 rages on, you will also be in a different workspace from your pair, surrounded by distractions. To learn from others, however, you need to bring your full self to the pairing session. Do what you can to avoid distractions. Close or minimize other app windows, find a work-only workspace if you can, and take breaks often, to keep both parties energized.
5. Teaching others
Here’s the worst-kept secret of almost all programmers: We don’t know nearly as much as most people think we do. And yet, here’s the best-kept secret about programmers, so well-kept that we don’t even realize it: We actually know way more than we think we do! The only way we can truly discover this hidden knowledge within ourselves is by teaching others, and there’s no better way to teach other programmers than through pair programming.
Be generous with your knowledge, not a domineering know-it-all. Intentionally listen for when your pair says things such as “How did you do that?” and “I’ve never seen that before” and “That’s really cool!” Those are all indications that you know something and your pair is likely inviting you to explain more. Since you’re often looking for those moments to learn more yourself, ask your pair if in those instances they’d like you to teach them more in turn.
How to do it remotely: Don’t steamroll your pair. While remote pairing, it’s especially easy to drown out your pair during your enthusiastic lecture about, say, consumer-driven contracts; you can even accidentally mute their audio and hide their video. Also, if you’re hosting the session, your pair might be experiencing audio, video, and screen sharing lag. Inquire often and intentionally about how they are doing and whether they have questions, especially if you’re in a senior/junior dynamic, such as when you’re onboarding a new team member. Be sure to check their engagement level, and encourage them to turn on their video if they have not. Remember to vocalize everything in detail, such as, “We’re about to use the same pattern we see here on line 157,” rather than, “It’s like that thing we did over there that one time.”
Using social distancing to become closer and more productive than you ever were
Right now you might find yourself at home, sitting in an uncomfortable kitchen chair at a table you share with your partner and kids, all of whom are also talking via their computers all day. Virtual happy hours and team game times do help ward off the quarantine blues, but your development team might be truly shook. So, shake it up for the better with remote pair programming. Ironically, via remote pairing, your experience of working from home might be more collaborative, more productive, and more gratifying than your co-located programming experience, and help you all produce software you’re more proud of than ever before.
