🌬️Clearing the air on pair programming cliches and misconceptions 🔍💡

Published in

Learn Agile Practices

5 min readJul 6, 2023

💥 Stop the 🤯 confusion about Pair Programming! 🙅‍♂️ Don’t fall for these common cliches and misconceptions. 😎 Get ready to upgrade your collaborative coding game! 💻👥

⏩ Introduction

Hey there, fellow developers! 👋✨

In the realm of software development, there exists a powerful practice that often remains shrouded in misconception and untapped potential: Pair Programming. 👨‍❤️‍👨

Pair Programming means that two (or more) developers work together on the same task, sharing a screen and keyboard.

While Pair Programming is a practice that has very few cons, but still it is far from being diffused as a standard practice — on the contrary, the most typical pattern is feature branches and async code reviews.

There are multiple reasons why this happens, and only a few of those are technical — and today, I want to expose the most common misconceptions and errors that people make when approaching Pair Programming.

I hope that with these issues I can help you all to beat your resistance and fear and start improving your work as a developer starting to apply this powerful practice in your daily work.

Two software developers coding together in pair programming. One is the driver typing on the keyboard, while the other is the navigator speaking and pointing with his finger to the monitor, realistic.

🌟 Myth busting Pair Programming misconceptions! 💪💻

When it comes to Pair Programming, people have a lot of beliefs about it that are totally wrong, probably due to not knowing enough about it or previous bad experiences.

I think it’s important to start with a bold statement: it is proven that Pair Programming works! It improves code quality and maximizes chances to avoid bugs and defects; having two developers working together at the same time brings the review at the same moment the code is written, which is the best timing for it.

Here is a quick list of the most common misconceptions about Pair Programming that are completely false:

Pair programming is only for beginners: Pair Programming focus is teamwork — while mentoring and knowledge sharing are some other good consequences of Pairing, they should be seen more as positive side-effects and not as a main objective of the session
It’s a waste of resources: some people perceive pair programming as inefficient since two developers are working on a single task. The reality is that the collaborative nature of pair programming leads to faster development in the long run. It reduces the need for code reviews, enhances code quality, and helps catch defects earlier in the process — in general, it prevents most of the unplanned work that typically comes up after merging some code.
One person does all the work: there is a misconception that in a pair programming setup, one person does all the coding while the other simply observes. Truth is Pair Programming expects that every person involved must alternate Navigator and Driver roles for the same amount of time.
It stifles creativity and autonomy: working with another developer actually enhances creativity by fostering diverse perspectives, encouraging brainstorming, and promoting shared ownership of the codebase. It also provides opportunities to learn new techniques and approaches from a partner.
It slows down the development process: considering only valuable metrics (lead time and cycle time, for example), you will notice that once developers learn how Pairing works, those metrics will improve thank the reduced unplanned work we already mentioned.
It requires constant communication: of course, communication is a key aspect of pair programming, but it doesn’t mean that the two individuals must be engaged in continuous conversation throughout the session. Silent periods for focused individual work are common during pair programming.
It’s suitable for all tasks: Pair programming may not be necessary or effective for all types of tasks. The best way to approach this is: make Pairing the default, but allow for solo work when it makes sense; typically, this means that the task is very simple, everyone would be able to do it and everyone would do it in a similar way, so there is not much space for discussion about design choices and not much need for knowledge sharing.

I’m sure a lot of other misconceptions exist, but those are some of those I heard most often and are totally, completely wrong. I cannot even say how much is wrong.

I’ve experienced Pair Programming in different contexts and with different people, and while sometimes it can be hard to learn how to communicate effectively, this investment is totally paid back from the benefits.

🐘 The elephant in the room: Feature branches and PR are bad! 🙅‍♂️

Let’s face the elephant in the room: the most common approach to developing and releasing new code for software development teams are Feature Branches and async Pull Requests / Peer Reviews.

This habit probably comes from the OSS world, where that approach makes a lot of sense because project maintainers receive PRs from people they most often don’t know and don’t trust, and might even be in a completely different timezone. In this context, PRs become a great tool to allow async feedback and management of that suggested new code.

This context is totally different from the software development teams of a digital product in a company: they share daily work, company values, product objectives, and responsibility over the codebase and all the technology used to run that product. They build trust working together every day, remote or not — it doesn’t matter here.

For a software development team to orchestrate their work, it makes a lot more sense to work in Pair Programming, or even better in Mob Programming (the whole team included), because this is the early feedback possible about the feature and the code.

If you work remotely and async, of course, this is not possible: while we can use modern tools to alleviate this and create a sort of “async pairing”, it’s not the same. I’m not saying that we should totally avoid async work but it’s important to be aware that async work pros are all about work-life balance and personal needs because from the productivity point of view working in sync with Pair/Mob Programming would be a lot better.

Being aware of this will help us to know the problems we will face, and find a solution to anticipate and solve them, enjoying even more this way of working!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

eXtreme Programming: Explained — Kent Beck describes how to improve your software development by integrating these highly desirable concepts into your daily development process. Pair programming is one of the practices suggested by XP.