Pair Programming fails to avoid
I often hear about bad experiences of Pair Programming sessions: I collected the 5 most common pitfalls I usually hear about with some solutions I’ve used to avoid them!
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Let's dive into today's micro-topic!
Common Pair Programming fails and how to avoid them
💡 Pair Programming is an Agile practice coming from eXtreme Programming that consists of two developers working together on the same task, in sync, and sharing the same screen and keyboard.
In this issue, I will assume you have a good understanding of what Pair Programming is - if this is not the case, you can easily find resources online: for example, you can have a look at Martin Fowler’s article about it.
I often hear about bad experiences with Pair Programming sessions: to help you become proficient with this practice, I collected the 5 most common pitfalls I usually hear about with some solutions I’ve used:
1. Pair Programming is too tiring
Naturally, Pairing requires some more energy than working solo, because it involves the interaction with the pair. While it’s always important to have regular breaks, it becomes fundamental when pairing. The ideal approach is to have frequent short breaks during the day, with a couple of longer ones. A time management technique can help, for example, have a look at the Pomodoro Technique.
2. Pair Programming is boring
This usually comes from devs who experienced sessions where they were looking at the screen for a lot of time. There are two problems to fix to prevent these situations:
Too few role switches: it’s easy to forget to switch if we are not used to Pair. A clear rule can help: two common approaches are chess clock and ping-pong.
chess clock: Set a timer and switch at the end of the time (great match with Pomodoro technique)
ping-pong: work in TDD and switch every cycle; for example:
Pair Programming with Ping-Pong TDD: A writes a failing test and switch. B pass the test, make some refactoring, write a new failing test, and switch. And so on. Unbalanced conversation: this usually means a lack of trust and psychological safety. To build them, strong-style pairing can help: the driver has to do exactly what the navigator says, the conversation is postponed to when some progress is reached. Make sure to match this with a switch technique (both chess clock and ping-pong can work).
3. Pair Programming is not allowed by management
Bold opinion alert!
I’ve never asked to my management permission to work in a specific way. Never.
My experience says that if you bring good outcomes, no one will ask. This can more easily happen when you are still in the process of mastering some practices, and what I usually do is shift the conversation to the outcomes. Management, or even better Tech Lead, can enable and facilitate the introduction and adoption of a practice in the team, but not force the team to do it or not do it. Have a look at this video from Emily Bache about leaders enabling best practices that use TDD as an example.
4. Pair Programming is only for some tasks
Make sure Pair is the default way of working: if nothing special happens, we do work in Pair. I think that working always in Pair is fine, but I understand sometimes the team feels the need for a more “lightweight” approach, especially when we are moving to Pair: I usually take inspiration from the Ship / Show / Ask Pair Review strategy from Martin Fowler and adapt it to Pair:
Ship means we can let a solo dev do the work; it suits well simple tasks such as adding a feature with an established pattern, fixing a minor bug, updating documentation, or improving a piece of code based on team feedback
Show means we will Pair but we can take it easier on switching because it will not last the entire day; it can be effective when the solution is clear but we want to share knowledge (it’s usually best if the one with less knowledge is the driver); some other use cases are: a refactoring decision worth sharing, or a weird bug
Ask means we will Pair as usual and it’s the default situation - this is what we do unless we strongly believe we are in one of the previous alternatives
5. Pair Programming works only if the two pairs have similar skills
There are no issues about Pairing two developers with different skills or experience, as long as there is psychological safety enough to let both express their opinions and questions with ease; dynamics might be a little different based on the seniority gap in the pair, but different doesn’t mean it doesn’t work.
For example, devs with similar seniority might switch more easily, but having proficient discussions might be harder. When the seniority gap is higher instead, it may be tempting to leave the more expert one on the keyboard longer, which is a mistake: balancing is always better but if you want more stability for a while, then do the opposite and let the junior stay at the keyboard for longer.
🧠 Test Yourself in 1 minute:
💡 Did you know? An interactive activity, like quizzes or flashcards, can boost your learning!Take a 1-minute quiz and test your understanding of the topic! 🤔 Don't miss the opportunity to boost your learning—try now! 👇
How can you prevent Pair Programming sessions from being too tiring?
Insights Recap
Pair Programming: two developers working together on the same task
The 2 participants have different roles:
Driver: the one typing at the keyboard
Navigator: the one that looks at the monitor and provides constant feedback and reflection
Pair Programming favors collaboration and collective ownership, shortening the feedback loop on code
Common pitfalls to avoid:
Too tiring: it’s fundamental to have frequent short breaks, with a couple of additional long breaks during the day. You can use a time management technique (such as the Pomodoro technique) to ensure to have proper breaks
Boring: Avoid unbalanced role time with a clear strategy on role switches, conversations, and decision-making:
Too few role switches use clear rules to make sure you don’t forget; two approaches are:
chess clock: Set a timer and switch at the end of the time
ping-pong: work in TDD and switch every cycle
Unbalanced conversation: work on building psychological safety and trust; strong-style pairing usually works to build such trust at the beginning: the driver has to do exactly what the navigator says.
Not allowed by leaders: You don’t have to ask permission about how to work. Make sure to be ready to express the benefits of the practices you use, but move the conversation about outcomes if they try to force you to drop some practices.
Only for some tasks: first of all, make sure Pair is the default way of working. It’s fine always to do Pair, but for a lighter approach you can try the following:
Let a solo dev to work for simple tasks with a known solution, minor bug fixes, or docs
Use a more easy Pair approach when the solution is still known, but there is some knowledge worth sharing
Pair remains the default unless we are sure to fall into one of the following use cases
Requires similar skills: different seniority or skills is not a problem by itself, as long as the conversation remains balanced. Dynamics might be a little different based on the seniority gap, but different doesn’t mean it can’t work.
Until next time, happy coding! 🤓👩💻👨💻
Go Deeper 🔎
Legenda
📚 Books
📩 Newsletter issues
📄 Blog posts
🎙️ Podcast episodes
🖥️ Videos
👤 Relevant people to follow
🌐 Any other content