Pair Programming

Want to know more about pair programming? Our Junior Software Developer John Holt explains what valuable findings he’s uncovered implementing this strategy.

7 min read

As a junior software developer, finding the right tools and techniques to help you learn a new language or technology can make a huge difference. While spending the last few months learning Erlang and Elixir, one of the techniques that I have found really helpful is pair programming. 

I will be breaking down the concept of pair programming and my experiences with it so far, including the benefits and different ways of utilizing this programming style.

What is pair programming?

Pair programming refers to the technique of writing code alongside other developers. Most typically this involves two developers working together on the same computer. 

Occasionally, there are more, which is known as “mob” or “ensemble” programming.

Traditionally with pair programming, only one developer can have control of the keyboard at time, and is therefore responsible for writing the code. This person is sometimes referred to as the ‘driver’. The other developer reviews the code as it’s written and advises the driver on the overall direction. This is often referred to as the ‘navigator’. 

It’s worth noting that pair programming can also be performed using online collaboration tools, rather than in-person. There is still a driver and a navigator, but Once the developers have agreed upon a direction, a driver and navigator can work concurrently in a remote setting on different portions of the code.

There are various tools that can be leveraged for remote pair programming, and later on I’ll be discussing my personal preference, an extension for Visual Studio Code called Live Share.

Benefits of pair programming

There are a variety of benefits to pair programming as a junior developer.

One of the key uses so far has been for teaching. For me, the best approach to this has been taking the driver role, while a senior developer supervises my coding in the navigator role. This ensures that I have full understanding of what I’m doing, and allows the senior to chip in to suggest alternative approaches, or demonstrate best practices. It also utilises the senior developer’s experience most effectively, with them guiding the overall direction and structure of the code, rather than focusing on the details.

The opposite arrangement, where the senior developer codes while a junior watches, can be even more efficient and result in quicker code generation. 

However, the disadvantage is that it can hamper participation from the junior developer. A less experienced observer is more likely to watch passively rather than contribute to the development. This will often defer to the more experienced developer’s judgement. They can also be afraid to ask simple questions, resulting in less effective learning. If you are going to use this system, it is important that the senior developer slows down from their normal pace significantly, and takes the time to check the junior’s understanding. 

In general, I still prefer the former arrangement, as being in the driver role has been better for my understanding of the code.

The other style of pair programming that I have found beneficial is working alongside a fellow junior developer. This allows us to learn from one another- whether it’s useful shortcuts in the editor, helpful tips for the language, or just something you wouldn’t have thought of by yourself. In this style, we tend to swap roles regularly, allowing both developers to take on both the driver and navigator roles. This is really beneficial as it allows both of our perspectives to be utilised in the software structure, as well as allowing us to play to our individual strengths when coding. 

When working alone, you have to fulfil both roles, whereas pair programming allows you to focus solely on one aspect of the code, resultulting in solutions that you may not have thought of otherwise. The ability to discuss your code with someone else who understands it also allows for quick and easy debugging (likely in part due to the ‘rubber ducking’ effect). And of course, pair programming can increase confidence in your code overall, because there’s another set of eyes to spot mistakes.

Remote pair programming with VS Code and Live Share

My editor of choice, Visual Studio Code, has the option to install the Live Share extension which I highly recommend for pair programming remotely. It is a very intuitive tool that allows you to see what your programming partner is doing in real-time.

When using Live Share, another developer is able to create files and edit the current project’s code from a different machine. You are able to see other users’ cursors in the code. You can also choose to ‘follow’ a particular user, which will track their cursor across all files in the project. This allows you to observe them wherever they are making changes. It is particularly helpful for more learning-based pair programming.

You also have the option to grant read/write permissions for the terminal, allowing any participant to run the code or tests or perform any other commands in the current directory.

To use Live Share, here’s what you’ll need to do:

  • You will need to find it in the VS Code extension marketplace, install the extension, and ensure you are signed in to VS Code with either your GitHub or Microsoft account. 
  • Once the extension is installed, you can initiate a Collaboration Session, which will copy the sharing link to your clipboard automatically. Here you have the option to restrict the session to read-only, if you want to prevent edits from other users. 
  • To grant access to another developer, simply share the link with them, which will allow access to the current project via either the browser or desktop versions of VS Code, for as long as the Collaboration Session is active. 
  • Once the Collaboration Session is ended by the host, all access is revoked, and another session will need to be initiated to allow further access.

Important tips for using VS Code Live Share:

  • Remember to terminate the Collaboration Session when you are finished pair programming. As long as the session is active, anyone with the link will be able to view and/or make changes to the code.
  • It’s important to be able to communicate quickly and effectively, so you will need to make use of a web-conferencing tool, such as Google Meet or Zoom, for verbal communication.
  • Alternatively, you can download the Live Share Audio extension which can facilitate audio calls within VS Code.

Final thoughts

Overall, I have found pair programming to be a valuable strategy and something I plan to utilise wherever possible in the future. Whether it’s learning from a senior developer or collaborating with a fellow junior, pair programming can be really beneficial and keep your mind open to different perspectives and ways of working. 

If you haven’t tried pair programming before, or perhaps it’s been a while, I highly recommend giving it a go. After all, programming can sometimes be a solitary activity, so working this closely with others could be a welcome change of pace and will surely foster some new ideas!

Keep reading

Learning functional and concurrent programming concepts with Elixir

Our latest developer Rhys Davey explains his first-hand introduction to Elixir, and his learnings along the way.

What we expect from Phoenix Framework 1.7

In this blog we look at what we expect and what we hope to see in the upcoming release of Phoenix 1.7.

Implementing Go Fish to Learn Elixir

Here is how the Erlang Solutions team designed and implemented GoFish in Elixir.