Join me as I share insights and discoveries from my journey in the world as a software engineering manager by day and tinkerer by night.
22 April 2022
At the beginning of the year 2022, an ex-google engineer made the case that pair programming is a waste of time. His argument was that since a company is employing two programmers to do the work at the same keyboard, the output must be greater than 2x the output of a single programmer for pair programming to make sense. Furthermore he argued that if two programmers pair, the pair always devolves to the least-common-denominator with respect to the performance of the pair, making them always slower. In my opinion the author of this statement only took efficiency and not effectiveness into consideration. When programming is just about typing, the above statements may be true, but when we talk about good engineering, it’s more than typing.
Software developers usually work alone. It’s all too easy to get stuck when trying to fix a bug based on an incorrect assumption, a hidden typo, or a gap in your knowledge. When you are pair programming, however, you are forced to work as a team. This automatically gives the code more “quality control.” Both partners use their shared experience and knowledge to solve problems faster as they arise. According to a study by the University of Utah, code produced during pair programming has 15 percent fewer defects. Having a partner on hand also lets you practice techniques like “rubber duck debugging.” This debugging method asks you to explain your code in the simplest terms line by line, as if speaking to a cute yet uninformed rubber duck. Your partner can more easily spot your own misconceptions and biases, helping you get back on track more quickly.
The “bus factor” should be a concern for all our software projects. If one person gets hit by a bus (which we most certainly don’t hope for), what will happen to the project? Is there valuable technical knowledge that would be lost forever (or take a long time to recover) because only one person knew about it? Pair programming does a lot to resolve this concern. At least two people should be familiar with every part of the code base, rather than information living with only one person.
Sharing best practices between partners leads to better overall code. In particular, having to be accountable to your partner discourages both members from taking any shortcuts or hacks. Pair programming encourages teams to build robust solutions that won’t create unexpected bugs later on.
The partners for pair programming are usually two experts or one expert and one novice. In this latter case, pair programming allows junior and new team members to pick up information from their more experienced colleagues. This can massively speed up the onboarding process. Taking turns “at the wheel” also allows the novice to apply fresh knowledge, getting direction from the expert on the co-driver seat. Learning by doing, in a safe environment on top of that, helps retention and the learning progress overall.
Finally, pair programming gives you someone else to talk to on the project who can empathize with you and help you solve your problems, so that you are not stuck spinning your wheels all day, especially in these remote-first times. This helps make the team as a whole more productive and happier. 96 percent of people who practice pair programming at work say that they enjoy their job more than when programming alone.
We all know that pair programming can be exhausting because of its intensity, so why not take it a step further and come together in a larger group and do a group-ensemble programming session?