A Simple Guide to Pair Programming
The Good, The Bad, and The Beneficial
It goes without saying that keeping your eyes on the road while driving is generally good practice. While it is possible to drive a car and read a map simultaneously, there is a higher chance that things can go wrong. After all, the initial task of operating a heavy piece of technology requires attention to detail.
Having another person read the map allows the driver to focus on the task at hand; driving the vehicle. Additionally, the navigator can focus on their own task at hand and deliver more clear instructions to the driver.
Similarly, coding with another developer can reap the same benefits.
Obviously, programming and driving a car are two very different operations yet they share one major similarity. If you are not careful, problems will follow. Luckily, if you take your eyes off your code it won't end in catastrophe, but if you are not focused, even a minor bug can sneak in, causing a major break in your app.
—Enter pair programming —
What is pair programming?
As the name signifies, pair programming is a software development technique where two developers work together on one workstation. The goal of this strategy is for:
“Developing higher quality code, faster while also reducing risk and spreading knowledge in an organization” -Alexandra Altvatera - What Is Pair Programming?
It is a common practice where one developer acts as the driver who writes the code while the other acts as the navigator or observer, monitoring what the driver is typing while also researching ways to solve their problem. Developers switch roles often, giving each a chance to look at the code with fresh eyes. This method strengthens the quality of code and minimizes the risk of error.
Pros and Cons of pair programming
This topic is highly controversial in the industry. There is a clear distinction between the developers who adopt this practice with excitement and others that view it as a waste of resources. Both are valid opinions that we will dive into further:
Pros:
- Develops a high quality of code.
- Strengthens interpersonal communication within the company.
- Improves team morale. One study showed that 96 percent of people who practice pair programming at work enjoy their job more than programming individually.
- Advances in time management skills.
- Opportunity for developers to share knowledge and techniques.
- Code review on the go.
- Two modes of thinking are better than one.
Cons:
- Cost. There is a commonly cited best-case estimate of 15% overhead for pair programming relative to programming independently. Although it may cost more upfront to pair program, it will increase the longevity of the code, resulting in less time and money later to fix and maintain it.
- Sustainability. Pair programming is not meant to be implemented all the time.
- Rotating from driver to navigator can result in ‘context switching’, resulting in a loss of time.
- Different skill levels. A senior developer programming with a junior developer would be drastically different than a junior programming with a junior.
Dos and Don’ts of pair programming
Similar to learning code, pair programming takes practice. My first experience with pair programming was a success. The group was engaging, respectful, and even silly which made for a fun learning environment. On the other hand, my second go with pair programming had challenges that I wasn’t expecting. It will be different every time, so become well-versed in the dos and don’ts of pair programming.
Navigating pair programming can have its share of challenges. It is imperative to acknowledge and practice the following points while programming with another developer to create an environment where individuals feel excited, heard, and respected.
Dos:
- Switch roles often — Allow each developer to switch between driving and navigating. A study was done by Dr. Sallyann Freudenberg that displayed pair programming teams and the amount they switched roles. One team did not switch roles which resulted in a lack of attention and communication. Another team switched roles 2–3 times a day, resulting in the navigator having a difficult time switching to the driver position. Switch roles often!
- Take breaks.
- Be considerate of your fellow developer.
- Expect a learning curve. It is a new skill that takes time to master.
- Keep the dialogue open between both parties. If you have questions, ask them. If you are tired, let your partner know.
- Be vulnerable. This is a skill that will take time to develop. Pair programming takes trust and vulnerability, which in turn creates a safe space to create and problem solve.
“Vulnerability is the birthplace of Innovation, Creativity, and Change” -Brene Brown- The Power of Vulnerability TED Talk
Don’ts:
- As the navigator, don’t micromanage or be overzealous when correcting simple typos. Pair programming is a team effort and it is important to allow the driver space to think.
- Don’t be impatient. An article written by Brigitta Bockeler and Nina Siessegger suggests the “5 seconds rule” which allows the navigator to wait 5 seconds before they say anything if they notice an error. Within that timeframe, the driver may already realize the error.
- Don’t let one person dominate the pair programming space. Every member should feel comfortable to input ideas.
- Don’t make anyone feel bad for asking questions. Everyone is at a different skill level. No one should feel shame for not understanding a concept.
Recommendations for future learners
- As a new learner, be open to the experience of pair programming when you have the opportunity. Give it your best effort before deciding if it is for you or not.
- Be open to screwing up or sounding dumb. That’s how we learn.
- Keep the dialogue open between you and your partner.
- Hold space for other opinions. Someone else may have a different way of doing things and that doesn’t mean it is wrong. It might be just what your code needs.
- Keep things light and don’t forget that you and your partner are on the same team!
Final Thoughts
Unfortunately, there is no clear winner on whether each team should adopt pair programming or not. In my personal opinion, I believe it has incredible benefits that programming independently cannot offer.
Pair programming allows the opportunity to vocalize your logical thought pattern while debugging or problem-solving. If a certain part becomes challenging to vocalize, there is a good chance your coding roadblock is hiding there.
“If you can’t say it simply, you don’t understand it well enough.” — Albert Einstein
Allowing the driver and navigator to focus on their assigned task, pair programming promotes a higher level of attention and quality to your code, avoiding any unnecessary coding catastrophes.
Although implementing pair programming may be costly at first, the longevity of your code will thrive, resulting in less money spent fixing code down the road.
Lastly, pair programming isn’t for every team or every individual, but you owe it to yourself and your team to investigate its potential.
Happy Coding!
Works Cited
- Alliance, Agile. “Pair Programming: Does It Really Work?” March 4, 2021. https://www.agilealliance.org/glossary/pairing/#:~:text=Pair%20programming%20is%20an%20important,algorithm%2C%20code%2C%20or%20test.
- Cockburn, A. (2002) Agile software development. Addison-Wesley, Boston
- McDavid, Sam. “The Pros and Cons of Pair Programming.” February 25, 2021. https://www.verypossible.com/insights/the-pros-and-cons-of-pair-programming.
- Plonka L, Segal J, Sharp H, Linden J. (2011) “Collaboration in pair programming: driving and switching.” Agile processes in software engineering and extreme programming (XP 2011). Springer, Heidelberg, pp 43–59
