Remote pair programming.

The issue

Possibility to work in a remote team is one the best advantages of being a programmer. These days we have a lot of tools that make it quite easy, such as Slack for real-time communication or Skype/Hangouts for conferencing (and it's working well even for SCRUM daily standup with many people remotely).
But what if we'd like to make a team work together on one solution? Like, literally, working on the same file, at the same time. If you have your team in the same office it's not a problem, both people can sit together and discuss. But we are talking about remote team here.

Remote pair programming


If you're not familiar with pair programming (often also called as peer programming) here's short explanation:

It's a technique where two programmers are working as a pair on the same issue. One, the driver writes code while the other, the observer or navigator reviews code as it is typed in

According to the research from year 2000 pairs spend about 15% more time on an issue than individuals, but at the same time resulting code has about 15% less bugs.
In my opinion it's also a great way to share knowledge and experience, and it's great way to:

  • verify candidate way of thinking and working during interview
  • mentor less experienced developer by their more experienced colleagues


There are various ways to do remote pair programming, starting from screen sharing with voice chat up to editors that let you work on the same file at the same time.
Let's list some of them and later I'll propose my favorite solution.

Screen sharing

  • Google Hangouts (requires account)
  • Skype (requires account)
  • Cisco WebEx (requires account, you have to pay for HD quality)
  • (registration and payments free)
  • Sylaps (like above)
  • Good old VNC or OS X built-in Screen


I suggest to look at all of them as each team has different needs, uses different technologies and may want to use different software.

My solution

When I'm working for remote clients and need to code with my co-worker in pair I'm doing it by using my tested setup which is basically quite simple, free and cross platform.
I chose this setup because it's free to use, easy to run and works fine whether user is running a Linux-based system or uses a Mac.


Vagrant is a software you might consider as wrapper for VirtualBox, VMware and other virtualization software. Its advantage however is to run virtual machines in headless mode so they're basically invisible to you. It's the best way to keep homogenous environment for all developers, which means they may use different OSes but still have the same development environment.
What's also a big advantage of Vagrant is Atlas which provides possibility to login with vagrant cli and share connection to your local machine remotely.


tmux is a terminal multiplexer

What is a terminal multiplexer? It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal.


I'm not sure if this needs any explanation, but it's one of the most used and most powerful editors ever made. Of course it's not full IDE in its initial state, but with a few plugins you can achieve what many more memory and CPU consuming applications are doing.

all three together

So what does my workflow look like?
I'm using my vagrant-pair-programming setup.
What is it doing is basically setting up default ubuntu machine and provisioning it for my needs using my own vim and tmux configuration files.
It also links my ~/code where I store my projects to /code
This way I don't have to clone repositories inside my vagrant machine.

Next I'm running vagrant share and sharing credentials with my coworker.
Then the other person can connect to my machine using vagrant connect and we're ready to work.

Important notes:

  • For every tool mentioned here that requires being hosted on user system, host should be on machine with fastest internet connection
  • Some people have personal issues with git commits being made by only one of two people working on same file. It's all about company culture.

I hope this short overview of remote pair programming tools will help you use this technique which is generally a fantastic opportunity to make your code better.

If you like this post and want to discuss feel free to comment and share.

Mateusz Kozak

Mateusz Kozak

Warsaw, Poland