Pair programming is a term that most developers hear as they begin their journey in programming when attending some educational institute. By the time most of them enter their first jobs, it's completely forgotten.
So let’s start there: What is pair programming?
Pair programming is when two programmers program at one workstation. The programmer who takes control of the keyboard is called the “driver”, while the other who is still actively involved in coding but is focused on the overall task is called the “navigator”. The two take turns switching roles based on a pre-determined time frame until the task at hand is complete.
So why should we pair program?
My first experience with pair programming came before I even knew the term. While studying computational methods during my engineering degree, we ended up working on group assignments solving complex Navier Stokes equations using MATLAB. Rather than divide and conquer my partner and I would sit at the same computer one coding while the other researched documentation, searched for next steps and spotted coding errors that would take a great amount of time to debug solo later down the line. We would switch now and then so that both of us “coded the assignment”.
It wasn’t till I joined my Web Development Bootcamp some years later that I would hear the official term. Instantly I was hooked. As someone with little coding experience, doing large projects with no guidance can be a daunting challenge even when you know what you are doing. The benefits of pair programming were extremely obvious. As unsure beginners pair programming gave us the benefit of having another person reassure us we were on the right track or logically contradict us if we were not. Planning the task became easier as we reasoned out loud our approach, our confidence grew and overall the task got done at a much faster rate. When developing our first full-stack app as a group of 3 students we continued down this approach as it was far easier programming together and understanding code on the spot rather than looking at a feature someone else created spending hours understanding their logic. Bugs were spotted faster, and when stuck on a problem the solutions came quicker. Moreover, there was a spread of knowledge as not everyone attending the Bootcamp was at the same level. Lastly, it was extremely fun! Getting to know people virtually, in online classes, can be quite difficult. This provided an avenue to work together while building a friendship.
So why haven’t workplaces adopted it?
Well to say companies have not adopted it would be incorrect. With agile software development becoming rapidly popular and the ever-increasing need for collaboration on large projects. Pair programming is gaining some popularity. Companies like Facebook, Shopify, Snap, Grubhub, Peloton and Vimeo have all utilized pair programming to some extent³. However, it does not seem to be an industry-wide trend.
The first and most obvious reason prohibiting companies from employing it is paying two people to do the job of one person. While it can be said that development time may take longer, the resulting code will overall be higher quality and safer, saving time further down the pipeline during debugging and refactoring. So overall it may not be 50% slower as one may assume but it would still result in the task being completed slower.
Second, it could result in less independent developers, as some may only have confidence when coding with others. It can also lead to insecurities and imposter syndrome if a junior developer(who is trying to learn) is paired with a senior developer.
Third, simple tasks do not require pair programming and would slow productivity down. In the case where both developers could write production-level code confidently pairing them up for that task would be inefficient.
Fourth, pair dynamics severely impact the results of pair programming. If two programmers silently sit next to each other while one programs and the other watches, it would simply defeat the purpose of the exercise.
The biggest reason however it seems is that most programmers seem to prefer to work alone on their schedules. Whether it's because they do not like explaining to others what they are doing, or it interrupts their “flow” or perhaps they just haven’t found the right partner to program with. It seems like pair programming may not be everyone's cup of tea.
So what are some of the do’s and don’ts of pair programming to avoid common pitfalls?
Do’s:
- always talk to your partner out loud, reasoning what you are doing and why
- be respectful and open to hearing out your partner. Have logical civil discussions rather than arguments
- switch roles often but not before the time to switch has been reached or both parties agree
- ask a lot of questions to challenge the status quo
- get the right collaboration tools
Don’ts:
- push the keyboard onto the navigator or grab it from the driver, and use timers to keep consistency with role switches
- if you are a novice do not program with another complete novice where the two of you introduce and reinforce bad practices to each other
- have a “watch the master at work” situation where a junior developer watches in awe as the senior developer works away solo
- enter into heated conflicts and debates which can lead to a complete communication breakdown
- try pair programming every simple problem, common problems do not need two minds to solve and should therefore be handled alone
So where does this all land us?
The global pandemic lead to a drastic change in the work environment as remote work specially in the tech world became the new norm. This change has led to developers becoming more isolated than ever. I believe pair programming could be the solution going forward as it helps employees engage with one another, and develop relationships and a proper team dynamic. It removes knowledge silos, increases team resiliency and helps newer team members get used to the code base much faster. It improves the overall quality of code, reduces refactoring and reduces bug incidences. It can also shorten the feedback loop as pair programming can lead to a “live code review”. If used correctly pair programming could be an effective tool in taking your dev team to the next level.
If you would like to give pair programming a shot in this remote work from home life click here for a great resource to get you the tools you need.
References:
[1] Mohankumar, B. (n.d.). Have you tried pair programming? C# Corner. Retrieved June 4, 2022, from https://www.c-sharpcorner.com/article/have-you-tried-pair-programming/
[2] On pair programming. martinfowler.com. (n.d.). Retrieved June 4, 2022, from https://martinfowler.com/articles/on-pair-programming.html
[3] Andaker, M. (2021, May 26). Learning about how successful companies use pair programming. The Deep Collaboration Blog. Retrieved June 4, 2022, from https://www.coscreen.co/blog/what-you-can-learn-from-how-successful-companies-use-pair-programming/#:~:text=Companies%20like%20Peloton%2C%20Stash%2C%20Grubhub,Pivotal%20Labs%2C%20and%20Sparta%20Science.
