12 Tips to Make Your Long-Distance (Programmer) Relationship Work
Overcome the challenges to pair programming with remote colleagues
I have always loved to pair-program with my colleagues. I find it very satisfying to spend an hour or two occasionally with my teammates and work on the same code at the same time. It gives us a sense of collective ownership. We both discuss what we plan to do in the next few lines of code before we write it — thereby validating its need and correctness before spending the effort to write it. This was all easy in the early days when everyone was working in the same office sitting side by side.
That was then. This is now. This is 2017. More teams are geographically distributed than ever before. Working with colleagues who are remote comes with its own set of challenges. Pair programming has had to adapt. We have to use different techniques when pair programming remotely.
As Stephen Colbert says, if you have been living under a rock for a while, pair programming usually leads to better code quicker while simultaneously reducing semantic errors. It also reduces the need for knowledge transfer because the knowledge is created and retained by multiple people resulting in code or configuration that is more generally understood than if a single person were creating it. Usually this is done by having two programmers sit side by side, one as a navigator and the other as a driver (to use an automobile metaphor) using the same computer. They take turns — one codes while the other watches carefully and gives suggestions to keep overall quality up. Several good techniques have been developed and scientifically validated over the years. But they all assume that both programmers are sitting next to each other. The techniques also assume that the end goal is a software application.
I recently had a series of pair programming exercises with a colleague working out of LA. We were not creating a software application per se. We were more concerned with software installations, configurations, CI, CD, etc — all geared towards as successful DevOps implementation and culture. I discovered and practiced a few good techniques that helped us be more successful. Here are a few useful tips and techniques we came up with and used.
1. Use a shared document to jot down notes
In traditional pair programming, the two programmers are sitting at the same table. They can use a whiteboard in the room or paper to draw flowcharts and to pen ideas. This is obviously not very easy over a video conference — which is what we used. So we used a google doc for real-time/simultaneous editing. We listed our goals as bullets. We could both brainstorm before the activity what our plan was and wrote the mini objectives right there on the google doc. We did not draw anything, but we could have, if we wanted to, using google slides (like a powerpoint presentation,) for example.
2. Have two or more screens
That brings up the setup we both had. I had a laptop and two 24 inch monitors. I used all three screens. Usually when I program by myself I only use the two big monitors and leave the laptop screen down. But when I share my screen with a remote colleague, I always share from my laptop screen. I also expect my partner to share from his or her laptop screen. The reason being, I cannot read small fonts easily. If they share their large monitor screen, the text appears rather crude on my monitor — especially if they are using smaller fonts. But if they share their laptop screen, usually 15 inches, I can easily enlarge it on one of my monitors. Everything will be legible when I view their laptop display on my 24 inch monitor.
In this setup where I acted as the navigator and observed, I used one of the monitors to watch his shared screen, I used my laptop screen to have a full screen live video of him, and the second monitor to take notes in the google docs scratch pad, dig deeper into error messages, chat with him on slack etc. By having his live video on the laptop screen kind-of gives me a semblance of him being right next to me — one of the tenets of pair programming.
3. Use a video conferencing software
Which brings me to the software we use for video conferencing. It does not matter much which software you use. There are several good ones in the market. You can use any software such as zoom, bluejeans, skype, teamviewer, jabber or hangouts. Thye all have the ability to show both the video feed and the screen-share at the same time on different screens. For those of you who cannot have three screens but would like to have this setup, you can easily use your phone or tablet as the third screen for the video feed. Or you could just put the video feed on a corner of your monitor.
4. Use a chat client to communicate chronologically
Definitely use a chat client. Again it does not matter which chat client you use. They are all good. Use the one your office provides. A chat client makes it easy to share error messages, links to solutions, code snippets, etc. You cannot use the google doc for this because it is not chronological.
5. Share a terminal window if you share a server
Since we are doing DevOps work there is yet another place we share during pair programming — a terminal window. Even programmers may use this, but maybe not. DevOps engineers usually work with servers. It is important that both of us are able to validate and troubleshoot issues beyond the one shared screen. There are times when the navigator needs to try things out on the server as a different user, for example. So we both login to the same server over ssh in our own terminal windows.
6. Take turns being the driver and navigator
Of course, we also followed the tried and tested techniques of traditional pair programming. We took turns being the driver. Usually, it is obvious who should be the driver. Sometimes, fatigue sets in and we may have to switch. It is important for the navigator to be patient and not be too quick to point out silly errors that the compiler or linter will catch anyway. People learn faster with that technique. There may be times when it is obvious that you need to point out an inadvertent mistake. When that happens, certainly point it out.
7. Feel free to interrupt your partner at any time
The important thing when working over distances is communicating clearly. If you notice the driver using some technique you are not familiar with, immediately ask him and learn it. Don’t worry about him losing his flow of thought. It is not that important in pair programming since there is a shared goal and there are mutually agreed upon objectives. One or both of us will remember where we were going when the quick learning is completed. If you don’t remember, just check your google doc.
8. Take breaks. And don’t pair too long
One important step in pair programming is taking breaks. In any circumstances, I could not work together for more than 2 hours in a day. After that it gets tedious. Since you are constantly talking and communicating, it can become tiring soon. Also extended periods of pair programming for DevOps engineers will get in the way of your other work. So take breaks as needed. But do try to stay focused for the 2 hours. In fact, put your phone on vibrate and let your spouse know you are going to be busy for two hours doing pair programming. Only answer if it might be urgent — or give your counterpart a heads up before the meeting starts that you are expecting a phone call or other distraction.
9. Work on an interesting topic
For a successful bout of pair programming, pick a topic both of you are interested in. Who becomes the driver and who navigates is usually easy to arrive at depending on your goals. Sometimes it is better to have the person learning something new to do the typing, at other times, it is better to have the person teaching do the typing. When both are experienced and it doesn’t matter too much, just be courteous.
10. Don’t let it drag on
Make your goals clear and time boxed. Break up the goal into three or four smaller goals and set 30 minute sprints for them. Don’t worry too much about refactoring (unless that is what you are doing). Just hard-code stuff to get the happy path working. But as soon as you get the happy path working, refactor it to remove the hard-coded values with variables, etc.
11. Work with other partners
Take turns with other people on the team when pair programming. Don’t always work with the same person — unless you are only two people on the team. In which case that’s fine.
12. Don’t overuse it
And finally, be aware that pair programming is not always the right tool. Even when it is the right tool, the law of diminishing marginal utility kicks in pretty soon. But when you need to pair program with a remote colleague, you can definitely use the above techniques for maximum benefit.
Are there other techniques we can use to make remote pair programming more effective? Please let me know in the comments.
About the author:
John Varghese is a DevOps Evangelist at Intuit encouraging the use of new technologies and sound DevOps techniques. He supports the Advanced Technology group in their adoption of AWS.
Separately, John runs the Bay Area AWS Meetup group focusing on the Peninsula and the South Bay. If you’re interested in connecting with John about either his work at Intuit or joining the AWS Bay Area Community, you can slack him directly on the AWS-Users-Slack channel or tweet him at @jvusa.