⏩ 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.
🌟 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! 🤓👩💻👨💻
Dan’s take 🙋🏻♂️
When I had my first Pair Programming expert, I didn’t know anything about it: I was lucky because most of my teammates were experienced with it, so they were able to drive me and other non-experts with the practice.
I was overwhelmed by the practice: we didn’t have any data on it, but we all perceived the benefits of pairing and soon it became our default way of working.
It was natural for me to start asking myself why Pair Programming wasn’t widespread in the software development world: the power of the technique is immediate to be seen, but yet the narrative about developers is more about the “lone wolf” type of programmer.
After 5 years, I think that the main reason for that is that Pairing is more difficult and requires more energy than solo development: you have to communicate out loud while coding, accept that half of the time you are not actively coding but only speaking, learn to take decisions together with another person and not on your own.
Still, have you ever seen something that improves your work, yourself, or anything else that doesn’t require commitment, energy, and focus? I never did.
The additional effort required by working in a team and not alone is totally repaid!
With Pair Programming, you might even decide to completely remove PR and work in Trunk-based, but even if you don’t you will soon realize that the PR from Pairing is easily and naturally less debated and discussed, because a conversation already happened between two of the team members so the result will most often be very aligned to the team shared best practices.
You will also notice that constant pairing will solve, or at least mitigate, common problems like:
-
knowledge sharing: people will learn from each other both technical and domain expertise
-
superhero developers: it will be harder to have someone that it’s a problem when missing - of course, there are always more expert people into something, but a couple of weeks of vacation or sickness will not be a problem because team members will know how to approach any problem that may occur
-
estimations: working in Pairs will naturally make estimation easier because you removed from the discussion the possibility to reason in hours per person in team since the team will work in pair - if you add Trunk Based - at least in “short living branch” form, you will have your way clear to remove estimation and start using real data for forecasting
While it may seem all good, and I definitely love both Pairing and Mob Programming (which is basically Pair but with the whole team involved), I met a lot of developers in the past that didn’t like Pair: that’s ok, we are all different, and you have to find a balance to introduce this practice when a person like this is in the team.
Most of the time people don’t like Pairing because they have done it wrong!
When Pairing, it’s important to respect a ceremony and take breaks - here are my main best practices:
-
choose a Pairing style for the session: there are various different styles, I typically choose between “chess clock” and “ping pong”:
-
in “chess clock” you set a timer and switch Navigator and Driver when the time is up, after a break - I typically stick to the Pomodoro technique, with 25 minutes of work, 5 minutes break, then another 25 minutes of work with switched roles, and so on…
-
in “ping-pong”, you enforce TDD to drive a continuous role switch: A writes a failing test, switch, B passes the test and writes a new failing test, switch, A pass the test and writes a new failing test, switch, and so on… here you can decide if naturally take breaks when one of the pair needs (but you risk that no one ever asks for a break!) or use a timer to force a break - I typically go with a timer
-
-
respect the breaks: there are typically 2 approaches to breaks: you leave everything how it is in the moment the time is up, or you continue for a couple of minutes at most to reach something committable, then start the break - choose the one you prefer, but treat breaks as mandatory, not optional, especially the longest one
-
decide what to do if the Pair cannot continue: if one of the pairing developers needs to go away at some point, for a meeting or for personal needs or whatever, ensure to agree on how to handle the work - if you decide that the other person will continue, share an objective and a hypothetic approach in order to maximize the chance that there will not be a discussion when the developer will be back; if the other person will not continue, be sure to share a set of rules of what people should do when they are waiting for a blocker - I suggested some in the "WIP limit” issue 3 weeks ago
Pair and Mob programming are great techniques, that are proven to make software development a better practice, not only from a technical point of view but especially from a business side.
Remember a rule of thumb from XP: when we fear something, we should do it more often. This is true with releases (that means CI+CD), but also with this kind of practice. If you are skeptical, start with some learning sessions or meetups, you will be amazed!
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.
-
29 Guidelines for Successful Pair Programming - Pair programming is an Extreme Programming practice of coding through an interpersonal process. There are many ways to get it right and many more to do it wrong. This practical reference offers precious tips for pair coders with all levels of experience.
-
Practical Remote Pair Programming - A practical guide for developers, development teams, and managers to successfully implement remote pair programming techniques and styles that better fit their organization's environment.
-
Software Teaming: A Mob Programming, Whole-Team Approach - In this book, authors share the "Software Teaming" style. They cover the techniques they use in their daily work, how they discovered this way of working, the benefits they see from Software Teaming, and the problems they’ve overcome.
📩 Newsletter issues
-
Pair programming: Why you should do it [Cumulative by Karim Fanous]
-
The value of pair programming in a remote environment [Engineering MKanagement Tid Bits by Sebastien]
-
Pair Programming, Code Review, The Great Migration to Mastodon, Clean SAPUI5 [Software Engineering Ecosystem by Klaus Häuptle]
📄 Blog posts
🎙️ Podcast episodes
-
Pair Programming (Developing Up podcast)
-
Agile Podcast #4 – Pair Programming (Agile podcast)
-
Pair Programming (Complete Developer podcast)