I’ve been pair programming on a weekly if not a daily basis for nearly two decades.

In essence, it is a simple practice where two or more developers sit down and write some code together.

Over the last decade though, I have been increasingly leading remote teams which are split across the globe, across the country or who are just spending more time working from home.

This means you have to practice remote pair programming instead.

In these days of enforced remote working and remote onboarding, I thought a few practical tips might help those new to the practice of remote pair programming.

Pair Programming

I first came across pair programming in the extreme programming era.

Despite it being a simple practice, I never took to it right away. That was because I tried to use it for everything.

Fortunately, I quickly realised that this might not be the correct approach for the teams I was working in. We experimented and found that it added the most value in a number of specific circumstances.

As well as being great for building the very difficult parts of a system, it was found to be extremely effective in the onboarding of new members of the team.

At the moment, there are lots of people currently forced to onboard remotely. It’s really, really hard to onboard remotely, especially if there is a large codebase.

That is where remote pair programming can help.

Remote Pair Programming.

Remote pair programming is again, a simple practice where two or more developers sit down and write some code together.

The big difference is that you can do it from anywhere on the planet.

For remote pair programming to work, you only need to be able to communicate clearly about the code you want to discuss.

In practice, this just requires a decent internet connection and some simple software.

Remote Pairing Tips

1. Only simple software is required.

There are lots of goods tools around for remote pair programming but essentially you only need 2 things

  • A screen share to see the code
  • A decent voice connection.

As long as you can hear each other clearly and both clearly see what code is being discussed, your good to pair.

There are some great tools which certainly add to the experience, however you only need the above to start.

2. If you don’t have the above, don’t bother!

I hope this one is pretty self-explanatory. If you can’t see and hear what each other is doing, you can’t possibly expect a remote pair programming session to go well.

Do not try this with bad tools or a bad connection – life is too short.

3. Follow the rules for remote meetings.

A remote coding session is very much like a remote meeting, so treat it as such.

In the same way as you would with a remote meeting, make sure that you schedule your session well in advance and ensure that there is a defined agenda. Make it clear what you will be covering in the session.

It’s then up to you to make sure you join on-time and ensure you are somewhere quiet where the meeting won’t get disturbed. Remember your going to be on speaker most of the time.

4. Integrate code often so you can swap roles.

You won’t be able to swap “Drivers” when doing remote pairing unless you are on the same code. So you are going to have to check-in and push your changes frequently. The other pair can then pull those changes and you can swap roles.

TDD is really important for this. To make things crystal clear, you may also have to do a few more steps than would be necessary when not pairing. You want to make sure whatever is vocalising in your head, is clear to the other person.

5. Use Feature Flags

If you are making a large fundamental change or a change to a delicate area of code, the use of feature flags can really help. Just add a simple toggle to turn the feature on or off. That way, you can’t really break anything.

6. Do some prep

It can be painful to be part of a pairing session where the driver is jumping all over the place to remember how things work.

So do yourself a favour and spend a little time thinking about what areas you might touch upon and spend some time familiarising yourself with that area.

Get yourself set up with the correct source checked out and built, key files loaded in your IDE and have any relevant documents open etc.

This will make everything much easier and It’ll also make you look good.

7. Keep it to one screen.

This one is just a preference. I just feel it’s much easier on the viewers if you keep the screen share to one screen.

If you then just have a couple of apps open – say your IDE and a shell for your build, its much clearer and easier to focus on the session.

8. Make it social.

One of the best things about pair programming is that it’s social. Quite often when sitting together you might go get a coffee together before you start and have a bit of a chat. If its someone you don’t know, its a great opportunity to find out about them. If it’s one of your closer teammates, it’s a great time to catch up a little.

It’s never going to be the same remotely but it is still a good time to have a chat and bond a little.

Wrap up

Every team will find their own best way of remote working and it will take some time. I hope that you might save time in finding your rhythm by following some of the tips above.

References

https://martinfowler.com/articles/on-pair-programming.html