As agile programming spreads into the IT space, development teams are increasingly relying on a concept known as pair programming [1]. Pair programming is an agile technique that involves two programmers working simultaneously on one computer. Both programmers use their own keyboard and mouse. Ideally, each also has a separate monitor.

In pair programming, one programmer acts as the driver (the person who actively programs), and the other is the navigator. Since both programmers have their own keyboards, the navigator can access the code directly at any time. This leads to those "wait a minute, I'll show you how to do that" moments where the navigator demonstrates something to the driver or simply corrects an error.

Pair programming proponents believe this technique leads to far cleaner code containing fewer errors. However, pair programming does put a strain on both programmers. Experts recommend that companies use pair programming regularly, but not every day for the entire day. The right chemistry between the two programmers is also important.

The technical requirements for pair programming (two keyboards, two mice, and ideally two monitors) are no problem for most companies; however, the picture looks a little more complicated when you combine pair programming with another recent modern office phenomenon: remote employment.

Pair programming concept can also work for two programmers separated geographically with the help of modern tools, such as webcams and headsets. Part of the concept, however, is that both parties need to be able to intervene directly into events, so the team also needs software that will promote interactive access in a programming context.

This article introduces two popular remote pair programming tools: tmate and Visual Studio Code.

tmate

Tmate [2], which is a fork of tmux (terminal multiplexer) [3], is a very simple tool that allows two programmers to work remotely by terminal. You can install tmate with your choice of package manager (the package is almost always named tmate). If you prefer to compile the source code yourself, you will find it on the project page [2].

The programmer who will manage the source code starts the tmate session locally by entering the tmate command. The command calls a local tmate client and a tmate server, which in turn establishes an SSH connection to the centrally hosted tmate.io server (Figure 1).

Figure 1: Based on tmux, tmate allows two remote developers to collaborate at the command line.

If you have never used SSH before, you first need to generate a key pair with ssh-keygen. If desired, you can also host your own tmate server, allowing for total control over the communication.

The connection uses gzip for compression to make the most of the bandwidth. On the centrally hosted server, the second programmer logs in using a normal SSH client. A tmate client then launches automatically. What is impressive about tmate is that the second programmer does not require any special software – only SSH. Tmate will display the complete SSH command at the bottom of the screen shortly after startup (Figure 2).

Figure 2: At the bottom of the screen, tmate shows the session's SSH address.

Both programmers can work simultaneously in a tmate session. Because they share a terminal, they can use all available editors (e.g., Vim and Emacs) without restrictions. At the end of the work period, the session can be terminated on both sides by typing exit. You can also invite other people to join the session, and, if you like, you can restrict the access rights to read-only.

Thanks to the manageable amount of data, the programming partners can still cooperate very well via tmate even with very narrowband Internet connections. If necessary, tmate will even work over a slow 3G mobile phone connection.

Visual Studio Code

Good old terminal editors aren't everyone's cup of tea. Another effective tool for pair programming is Microsoft's Visual Studio Code (VSC) [4], which is open source software and available for Linux.

VSC is well equipped for remote pair programming. With the Visual Studio Live Share extension [5], several people can work on a project at the same time. After installing the extension, they have to log on to a central server; this can be done via a GitHub account, for example. Unlike tmate, however, this server cannot be hosted on a local network. After logging on to the server, the developer starts a share and then sees a URL displayed and copied directly to the clipboard. The developer informs the pairing partner, who then has access.

The driver and navigator can now work on the code at the same time. It is even possible to work with two cursors at different places in the same file. The names of the people involved appear above the cursors. However, this rarely occurs in normal pair programming.

The option to see selections on both sides of the session is very handy. Given simultaneous use of an audio connection, this allows for scenarios in which the navigator selects code to show that something is wrong, eliminating the need to reference code line numbers.

As an added benefit, the two participants can choose their favorite colors and settings. The text can be white on black for the driver, for example, while the navigator can choose black on pink.

Things get really exciting during debugging. The VSC debugger started by the driver can also be used by the navigator. The navigator doesn't even need to pre-install the appropriate software (e.g., Node). Both can set breakpoints and browse the program bit by bit.

If you develop web applications, you will want to see the results of your work in your browser. For this purpose, the driver can enable the port where its local system is running for the navigator (e.g., 8000). The driver can then access http://localhost:8000 in their browser and use the application on the driver's system.

From a technical point of view, VSC offers nothing new for Linux professionals, but the simplicity of this solution – and the ability to use it across different operating systems – is impressive.

Conclusions

Tmate and VSC require little bandwidth, and both impress with the perceived speed. Nevertheless, the physical limits mean that a pairing session between New York and Sydney, for example, will always be a touch slower than cooperation between nearby locations. In spite of the delays, however, remote pair programming often works better than working alone.