7 Remote pair programming best practices Q&A - Part 2

5 more best practices about remote pair programming. Let’s deal with a painful headphone, a todo list, time difference, eye contact and continuous improvement

This is the second post in a mini series about Remote pair programming best practices. In the previous post, I gave answers to 2 questions about remote pair programming:

• How to deal with the connection lag?
• How tiring is remote pair programming?

If that rings a bell, start with this first post and get the full story.

Here are 5 others best practices.

The headphone is hurting me!

I remember the headphone was hurting the top of my head. I had to hack it with a small cushion so that it would be more comfortable.

We were remote pair programming pioneers in the company. It was difficult to get budget for top notch headphones. Nonetheless, here again, my advice is to buy the best you can.

Another option is to use a loud speaker and the camera’s mic. This setup works great as long as you are the only one remote pairing in the office. If you are not, all conversations will blend together in an unintelligible mess!

We used to keep a todo list on paper, how can we do?

As Ahmad said in 10 Pair Programming Best Practices Q&A, it’s a great practice for the navigator to maintain a TODO list of some sort. It reduces driver interruption while keeping note of improvements points. Usually, when the driver switches, the sheet switches hand too. This cannot be done when remote pairing…

Any online concurrent editor will do the trick here. We had success using Google Docs, but Office 365 or even a mind map would work.

As a side-note, this can be particularly useful for the Mikado Method. Regular readers will know about it. It’s an incremental refactoring technique that relies on a graph of small steps.

How can we deal with the time difference ?

We had 1 hour difference between Paris and Beirut. 1 hour of time difference is not a lot, but still needs to handled. Ahmad went over this topic in 10 Pair Programming Best Practices Q&A.

1. Have an up-to-date shared document of all the story’s tasks. Any of the pair should be quickly updated on the story’s status by just having a quick look at the document.
2. Don’t leave un-committed code when you leave your desk! If you are using Git, create a branch for your un-committed code, if you are using perforce use the shelve feature.
3. Every morning, the pair share their calendars to be aware when they have separate meetings
4. Use the time difference to finish any paperwork you need to do alone.

I’d also add the following:

💡 A time difference while remote pair programming is a perfect opportunity for learning and deliberate practice.

I’ve already done some remote pair programming with people in India. We had 4 to 5 hours of time difference. We could only pair for 2 to 3 hours every day. Nonetheless, it was very useful.

Any other trick?

Eye contact

Facial expressions are super important when discussing code or design. Communication is a lot more fluid when we manage to keep eye contact as we work.

Unfortunately, we never managed to completely fix this issue. Ideally, when you look both at the code or at your buddy, he should feel you are watching him in the eyes… More easily said than done.

Here is a setup suggested by Justin Gordon on his blog:

By Justin Gordon from his blog post Remote Pair Programming Tips Using RubyMine and Screenhero

Technology might improve this in the future:

• Cameras behind and at the center of our screens
• Augmented reality glasses

Until then, this looks like the best setup I found.

Continuous Improvement

We did not get there from day 1, it took us many retrospective iterations.

💡 Our Do It Yourself culture helped a lot to get remote pair programming working.

Be ready to discuss and experiment with your remote pairing setup. At some point you should find something that works well for you.

You don’t have to wait for the sprint retrospective to improve. I recently attended Woody Zuill’s (great) workshop on mob programming. He used to do daily mini-retro at the end of every day.

If it hurts, do it more often. [eXtreme Programming moto]

Try it yourself!

Remote pairing might seem daunting at first. I hope our experience will help you to get started better than we did. Give it a few tries and see how it works for you. Who knows, you might decide to make it part of your daily practices!

We’d love to hear your own pair remote pair programming best practices. Comments are more than welcome!

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!