Why even bother? 🤔
Pair programming is one of the most efficient practices for building software. It was first coined in the Extreme Programming Practices book by Kent Beck. There are many reasons why pair programming is useful and widely used in software companies.
- Software is a team player game - Pairing gives flexibility to the team by enabling individuals to cover their colleagues when necessary. Since pairing is a handy tool for knowledge sharing, people are easier to cover their teammates.
- Reduced knowledge silos - Pairing strength collaboration; hence knowledge is shared among the team, enabling them to make better decisions, reduce silos, and increase performance overall.
- Code Review On-the-go - Since you have more than one pair of eyes while pairing, the quality of the code tends to increase.
- Focus - Working with a colleague creates a more focused environment where getting distracted is challenging.
- Team flow - Having all the above, pairing contributes to a constant flow of sharing, collaboration, feedback, and efficiency.
Pair programming is a core software engineer practice, but it requires some attention to get the most out of it.
Types of pairing
There are different types of pair programming; there is no better or worse. It's just a preference style.
- Ping-Pong -> This technique requires a Test Driven Development approach. One person is writing the failing unit test, and the other tries to make it green. After they do that, then the next failing unit has been written and so on.
- Driver - Navigator -> Driver is the one that has access to the keyboard and focuses more on the syntax sugar of the language and typing. In contrast, the Navigator has a broader understanding of the problem, directing the driver.
- Unstructured -> This could be anything that works for you. Many people must follow a specific type and focus on what fits them.
There is no right way, honestly. If it works for you, then go ahead and follow your style. If it doesn't, try to reflect, readjust and re-try.
Research & Investigations 🔍
I've heard engineers saying that pairing is inappropriate for tasks requiring some investigation, also known as spikes. This is totally not true. On the contrary, pairing is quite efficient when investigating. Here is how you can approach spikes while pairing.
- You need a plan. Work together to ensure you understand the requirements and create a plan that will ensure you are on the same page on how to approach the problem.
- Split work accordingly and start the investigation.
- Timebox the investigation so you don't end up in a rabbit hole.
- Come back, and present what you found and learnt to each other. By presenting to each other, you verify your understanding and get fresh ideas for your findings.
- If you still have unknowns that need to be resolved, you can repeat the process.
Effective pairing 📈
We will now discuss some techniques on how to make your pair programming more effective.
Planning 🧭
Wait to jump immediately into coding when you start working on something together. Make sure you understand the problem, devise a solution and lay down your plan. It's essential to make sure you are aligned on the approach. Ideally, you want to write the steps down so you can always refer back and readjust if needed.
5-Sec Rule ⏳
When pairing, you will be tempted to correct every small mistake your colleague makes when they have access to the keyboard. Please don't do that. When you, as a navigator, see the driver make something "wrong", please wait 5 seconds before you say anything. Most of the time, the driver has it in mind, but they are just in the flow and thinking of fixing it soon.
Don't pair 8 hours a day 😰
Pairing is energy-consuming and can be exhausting for both parties. It's also not sustainable, as people have other stuff to do throughout the day other than the specific task, e.g. checking emails, having 1:1s, and meetings. Make sure you are aware of your emotions and energy and adjust your pairing accordingly.
Avoid micromanaging 🫵
When pairing, try to avoid micro-managing your colleague. I've seen it many times, and it has the counter effects of what pair programming should be. It creates tension, restricts creativity, and makes it a frustrating experience. So please avoid telling your colleague what to do all the time and give them time to think, ask, suggest and code. You can always communicate the issue in case you are the one that's been micro-managed.
Switch keyboard ⌨️
If you've been typing for quite a long time, ask your pair to switch roles or vice versa. Swapping keyboards and roles have a positive impact on performance. Changing perspectives gives fresh ideas, clears the mind, and recharges interest in the problem. Shared active participation keeps the energy level up and helps us learn and understand things better.
Feedback 💭
After or during your pair programming, try to ask for feedback. Many people need help with this since they think it will create a tense environment. Giving constructive feedback is not easy and requires some skills and practice. Unfortunately, to pair effectively and build strong relationships with your colleagues, you need to ask and receive feedback respectively.
Tools 🛠
Several tools will help facilitate easier your pair programming session more, especially if you are working remotely.
- Code with me - A tool for programming in the same Jetbrains IDE.
- Live Share - A tool for programming in the same VScode editor.
- Pop - A screen-sharing tool that markets itself as "Perfect for pair programming."
- Miro - A visual collaborative whiteboard tool.
Wrap up
Pair programming was controversial when it was introduced, but nowadays, this is one of the most well-known and applicable practices across our industry. Getting good at pairing is crucial and requires practice. Next time, follow some of the advice in this blog post and see how it goes.
Subscribe to my newsletter
An irregular digest about tech, software, and mentoring.