The first time I heard about pair programming (2005), it was pitched to our team as a software development technique that involved two programmers working together at a single computer, sharing the same keyboard, mouse, and screen. Although it had its advantages, most of the time, it was a painful, bumpy and an un-smooth experience. Eventually it was used mostly to pair a senior engineer with a more junior one to transfer knowledge and experience. On my first week in Microsoft, that is how I speed-learned what was new in C#, but in any case, it never stuck with me.
When the pandemic hit, working mostly remotely, sharing a physical computer became a challenge, but opened the door to a more efficient approach of pair programming. For some companies, working remotely was a traumatic event but Microsoft took the challenge and improved greatly collaboration tools as Microsoft Teams, VSCode Live Share and GitHub Codespaces.
During the pandemic, our team worked exclusively with mob or pair programming for months, and we have produced thousands of lines of code and completed dozens of user stories using this approach. We have worked across three different projects, and we think it is important to share some of our learnings. But before sharing how we did it, let’s share why we did it.
Why Pair Programming?
One of the key benefits of pair programming is that it improves the quality of your code. Studies have shown that code written through pair programming has fewer defects and is more maintainable than code written by an individual. In our experience, we have found that pair programming allows for continuous code review and eliminates the need for code to be passed back and forth between team members, leading to fewer defects and more maintainable code.
In addition to improving the quality of your code, pair programming can also boost productivity. We found that by working in pairs, we are able to complete tasks in about half the time of doing it alone. This is likely because pair programming allows efficient problem-solving, as two people can work on different parts of a problem simultaneously. It might feel slower, but has benefits of efficiency rather working individually. Our team members feel that pair programming helped them to understand the context of what they were trying to accomplish and gave a clear focus or goal to work towards.
Examples:
- On the last sprint, we decided to work individually on some small tasks. During that time, everybody knew the details of the codebase, anyone could virtually take any task, avoiding gaps in knowledge and ramp up time.
- During a bug bash in the project, anyone could take any bug and solve it, avoiding bottlenecks of waiting for one person who knows a specific module.
Pair programming has also allowed us to reinforce our Engineering culture, which puts best practices and collaboration first. New team members quickly adopt the best (and sometimes the worst) practices and collaborative culture through pair programming sessions. When we emphasize the importance of collaboration, it becomes evident in the congruence of the team’s approach, when the first thing they do is collaborative work.
How to make pair programming a painless experience?
To facilitate pair programming, we have an optional working sessions planned every day. This allows everyone to just jump-in and work together, and then split into smaller groups after that. This approach has been particularly helpful for new team members, as they don’t feel overwhelmed with a big codebase. It is a similar concept of the humble water cooler, which help team members feel connected through code. It also forces collaboration between all team members, by blocking a dedicated time in our calendars.
User story assignments when pair programming
When everyone is responsible for all user stories, then nobody is, which might cause tasks to be stuck or to not be completed. That is why user stories should have only one assigned person, someone who is responsible to see the user story completed up to the end (and usually the person that creates the pull requests). This also eliminates the problem of engineers being afraid to touch code because the they feel “it’s not their code”.
Tools
GitHub Codespaces
GitHub Codespaces is a game-changer for pair programming and we make sure it is part of our team development environment. Our first goal in any project is to setup a codespace. Before creating a docker container, compiling the project on a local machine, or adding a VSCode plugin to our local development environment, we ensure we update our codespace first. GitHub Codespaces is our primary development environment, and we prioritize it throughout our development process. For instance, we make sure to present every demo on a GitHub Codespaces environment, and when we create a pull request to update any quickstart instructions, we ensure that the instructions for Codespaces are updated first, along with other development environments such as local development environments.
As a cloud-based development environment it makes it easier and more efficient for us to collaborate and code together in real-time. New team members can just go to our GitHub project, and start coding in seconds, without the need to install anything on their local machines. It provides a streamlined and integrated solution for pair programming, allowing you to focus on what’s most important – writing great code.
VSCode Live Share
Another tool that we love is VSCode Live Share, it’s specifically designed for pair programming and enables you to work on the same codebase, in real-time, with your team members. With LiveShare, you no longer have to struggle with complicated setup processes, navigate confusing configurations, shrinking your eyes to see a small monitor, or physically switching keyboards. Simply share your development environment with your team members and you are ready to start coding together. LiveShare is completely integrated into Visual Studio Code and Visual Studio, and includes the ability to share terminals, debug sessions, and even control the host machine. Combined with GitHub Codespaces provides a powerful toolset for pair programming.
Tip: All our VSCode extensions (including Live Share) are shared and configured and available in our base devcontainer.json. This ensure all team members the same have available extensions, and we use quite a few of them!
Conclusion
Software Engineers take great pride in their code, and nothing instills a stronger sense of ownership in a codebase than writing it themselves. There is also an increased sense of understanding the codebase, which increases a sense of ownership as well. With the use of a good defined culture, processes and taking advantage of the latest cloud-based, development environments pair programming became a game changer.
In conclusion, pair programming has been a powerful software development technique for our team and our company. It has improved the quality of our code, boosted our productivity, and strengthened our team dynamics. While it may have its challenges, the benefits are well worth the effort.
Acknowledgements
This blog post was also pair programmed and reviewed by Emmeline Hoops. There was significant feedback from Renato Marciano and Yani Ariunbold. They are my mob programming team. Also special thanks to Marcia Dos Santos, Wendy Reinsel, and Ronnie Yates for their support. If you want to talk about the challenges and benefits of pair programming you can contact me anytime.
