Bridge on the Olentangy River (Columbus, Ohio)

Pair programming is an agile development technique where two developers share one workstation, one of the developers writes the code while the other developer immediately reviews the output. There are a few variations on this, for example, some approaches require that the developer observing actually navigate and direct the developer controlling the keyboard.

I have been fortunate enough to have worked with some of the best developers from all over the globe, the subsequent success of those projects have varied widely but I genuinely believe that the concept of remote pair programming was critically important to our development work and strengthened team cohesion regardless of the relative geographic location of the developers.

So what makes for a positive remote pair programming experience? All the things that make for a good local pair programming session but with a few minor prerequisites that can minimize the disadvantages of not being in the same location.

Shared source code

The first and most obvious item is to have open and equal access to the source code. Regardless of who is writing code, or reviewing becoming familiar enough with the code to contribute meaningfully is important. In 2016 the idea of a public repro is basically synonymous with GitHub, and it is actually a great choice.

Organize your communication

I personally default to Skype because you get screen sharing, video conferencing and messaging that pretty much everyone with Windows has it installed, although WebEx works fine but with some cost overhead. Whatever your choice here, go for the most ubiquitous and easy to use software. There is nothing more annoying than spending half your time fiddling with the communication.

If you need to share files or code snippets I would suggest a public gist. Gists are a great way to share your work. You can share single files, parts of files, or full applications. You can access gists at https://gist.github.com. Every gist is a Git repository and that means that it can be forked and cloned just like everything else.

Don't waste time

Set the time for your work, be punctual, know exactly what you want to work on. Always end the meeting understanding what your responsibilities are before your next meet. If this is something you do in your spare time this doubly important. Time is our most precious finite resource, use it well.

Sharing responsibilities

Decide who is doing what before you start, I find it is better to mix it up, sometimes drive, sometimes guide. If you feel less confident driving maybe consider coming prepared and showing what you have. I know many developers do not feel confident developing code extemporaneously, and this is fine, but you should be willing to take up the slack reviewing and navigating.

Continuous positive feedback

While you are working together be compassionate and thoughtful about your suggestions, we all feel a little vulnerable writing code in front of others and it is important to give each other permission to write code that may need further work. Consider again that writing code from on the spot is an acquired skill and it takes time to master, but our words and tone can help both parties feel comfortable doing it. If you are working via Skype without video it can be difficult to gauge the intent of your co-developers words without those visual social cues kind words can be poisoned with our own insecurities.

Any other suggestions?



Comment Section

Comments are closed.