March 25, 2020

Paired Programming

Here’s my guide on pair programming, originally written to conduct “office hours” training with boot-camp developers.

The Goal

When programmers pair on a task, they work synchronously together to write clean, functional code that passes all test criteria. This practice leads to shared knowledge of the written code, higher quality of the work product, and professional trust between the programmers pairing together.


We pair synchronously – that’s to say, working on the same task at the same time. This means sharing the same tools used to complete the task. Some offices that regularly conduct paired programming have dedicated work stations to achieve this. Often, in an office setting with less frequent pairing sessions, a shared keyboard suffices; one or the other developer uses their own work station and the keyboard passes between the driver and the pair. When one or both pairs work remotely, screen share during video chat, a remote server using tmux, or an IDE plugin facilitate the pairing session.

I’ll focus on the remote tooling for this setup. I’ll cover Visual Studio Code, Atom, and tmux as these tools closely integrate with the “typical” programming tools without use of an external screen share application.

Visual Studio Code

  1. Click on the Extensions tab
  2. Search for and install “Live Share” by Microsoft
  3. Search for and install “Live Share Extension Pack” by Microsoft
  4. Restart VS Code

You now have an additional tab for Live Share, which allows you to Join or to Start a collaboration session. Once a session starts, a pair may join the session to participate. The extension pack installed in step 3 enables voice audio during the session – no external calling software required!

Atom by Github

  1. Go to Settings and click Install.
  2. Search for and install “Teletype” by Github.
  3. Restart Atom

You can now start a “portal” to collaborate with other developers. You can share a URL link to the portal with collaborators to edit files in real time.

The workflow here is very similar to that of VS Code, with the exception that there’s no built-in audio tool. You will need to open a separate voice chat to speak with your pair.


  1. Open a terminal and install with brew install tmate (assuming you’re using MacOS, directions for other operating systems can be found here)
  2. Start a session with the terminal command tmate
  3. Share the ssh command output by tmate to allow your pair to access the shell.

tmate uses tmux - a “terminal multiplexer” - for configuration and commands. Programmers familiar with development using tmux will be comfortable with this approach. It’s not as easy to use as VS Code or Atom, but it does allow for more advanced pair programming tasks.

As a terminal based tool, tmate does not have audio built-in and an external voice calling tool will be required.


Successful pair programming emphasises the pair, and not the programming. In other words, your task while pairing revolves around your communication effort with your companion – writing code doesn’t matter so much as communicating about the code being written.

Different pairs may find different ways to succeed in communicating with each other, but one reliable way to conduct a productive session is to use a known workflow. The “red-green-refactor” workflow from Test Driven Development (TDD) is one such approach, and I find it works quite well, especially when pairing with someone new.


Once the setup is complete and the session established, one programmer, let’s call her the driver, should create a new git branch from trunk and run all the tests in the project (if there’s too many, run a relevant subset of tests). Once satisfied that the project has been setup properly and pre-existing tests pass, then the driver should write a failing test representative of the task at hand.

Just one such failing test suffices.


With one failing test, the other programmer, let’s call him the pair, should write code that makes the test pass. It’s important in this step that the control of the cursor changes from the driver to the pair. Both programmers are allowed – no, encouraged! – to comment verbally as code gets written, but the physical writing of the tests and code ought to change hands. This allows collaboration to take place, emphasizing complementary contributions to the task at hand and disallowing any one individual from assuming complete control of the exercise.

Just getting the test to pass suffices.


Once the test is green – i.e., once it’s passing – the driver and the pair communicate further about the code that’s been written thus far. Some topics for discussion:

  • Is the code correct?
  • Is the code legible?
  • Is the code performant?
  • Does the code meet the teams’ linting standards?
  • Do the tests cover all the anticipated behavior of the code?
  • Do the tests adequately describe the requirements of the code?
  • Have all the requirements been met?

The programmers may make modifications to the code itself, consider other patterns or approaches, and make improvements if they agree on those improvements being a good tradeoff (effort versus benefits, maintainablity versus completeness, etc.).

Once done, the driver returns to the “red” stage to write the next test and resume the process.


When pairing, a commit to the code repository should be singular and focused on the task at hand. This follows similar guidelines on good Git etiquette in general. I think there’s a special importance here since the commit represents collaborative effort – both programmers deserve equal credit for the work, and both should be satisfied that the work clearly represents a single, completed task. It’s like song-writing: everyone involved wants credit for the effort, not just for this song, but also to gain access to further collaboration in the future. You want the end result to be tidy so you can point to the success and replicate it with others.

Content by © Jared Davis 2019-2020

Powered by Hugo & Kiss.