Pair Programming
- John Holt
- 6th Oct 2022
- 8 min of reading time
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.
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.
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.
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:
Important tips for using VS Code Live Share:
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!
Pawel Chrząszcz introduces MongooseIM 6.3.0 with Prometheus monitoring and CockroachDB support for greater scalability and flexibility.
Here's how machine learning drives business efficiency, from customer insights to fraud detection, powering smarter, faster decisions.
Phuong Van explores Phoenix LiveView implementation, covering data migration, UI development, and team collaboration from concept to production.