Seven ways to explore the power of pair programming
For the majority of my career as a programmer I believed that I was way more productive when working solo. Had you been on my team back then, you would have found me almost exclusively wearing noise cancelling headphones, in a deep state of focus, trying to turn out lots of high quality code.
These days my beliefs and my behaviour have changed almost 180 degrees. I spend very little time developing software all on my own. Instead, you’d more likely find me working closely with my peers. I’d probably even ask you to pair programm with me, join a mob programming session or to participate in some whiteboarding.
If you were an old friend and had just met me again after a very long time you would definitely stare at me and wonder what had happened to me. How did this change come about?
The honest answer is that I don’t know. It didn’t happen all at once. Instead, it was a journey filled with lots of experimentation, many new ideas and plenty of stories. I learned as much as I could about Agile and Lean software development. I read about establishing trust and building relationships. I’ve adopted the Socratic method and studied Skepticism. What’s more, I even got to meet and befriend so many amazing people!
All of these and many more things have convinced me that I can only reach my full potential by working closely with others. Consequently, I will seek out the wisdom of my peers during many of the typical activities in software development. Some activities benefit a lot from performing them together, others don’t. But that’s okay — for me the goal is to keep experimenting, learning and improving. Making mistakes is part of that process.
Here’s a list of activities that, in my experience, offer many benefits when they are performed together. If you’ve always performed those activities solo in the past, you might just discover a new powerful tool by performing them together with someone else.
1. Onboarding
If you’ve decided to welcome a new member to your team, one of your main concerns will be to set them up for success. Usually new members are provisioned with a computer, get access to the source code and are then encouraged to work on a small bugfix or feature. But because most new members don’t want to interrupt their colleagues, they often stay quiet and get stuck instead of just asking.
I found that pair programming with your new colleague leads to better results. Sitting down together and working on the same thing benefits both parties: the new member learns quickly, while the peers get to see their work from a new perspective.
2. Design & Architecture
How useful is the perfect architecture when it only sits in your brain, some drawer or a Wiki page? With techniques like architecture whiteboarding sessions you create an environment to discuss those topics that really matter to your team. If you involve the entire team, you build a shared understanding of where you are and where you go. This is the most effective form of architecture that I have seen yet.
3. Testing
Writing great test cases for your own code can be challenging. Somehow when I’m thinking about getting my code to work in one way, I forget to think about all the ways in which it could fail.
I found that techniques like ping pong pair programming allow one developer to focus on making the code robust, while the other can focus on trying to break it. This creates a fun little game that often leads to better code.
4. Implementation
Code that I write together with others tends to have a higher quality than code I write on my own, especially when using strong-style pairing. I think this is for many reasons:
- One person can focus on the big picture, while another person can focus on the small details.
- When you explain your idea to someone else, it helps you to separate the essential from the inessential, often leading to simpler design.
- You can hold each other accountable to follow your team’s practices, for example constant refactoring, test automation etc.
5. Code reviews
I think of pair programming as the best code review technique I have used in my career. It beats any form of pull request, because you receive feedback on your code immediately and you can have a real conversation about any issue. And even more: no more waiting for approvals!
6. Debugging
You’ve probably already been in one of these dreadful situations where you had to fix a really nasty defect. If you ever had to investigate a Heisenbug, you know what a terrible toll on well-being it has.
I found that investigating difficult problems with the entire team can lead to faster results. Not only do you get new ideas about what might be causing the issue, but you often spot flaws in your own logic when explaining your theory to someone else.
7. Deployment
Deploying code to production can be scarry at times. Despite having done your best to prevent an incident, occasionally Murphy might be out to get you. If that happens, you want to respond fast, but without panic. Panic will only make things worse.
I like to have at least one other team member around when deploying code. Most of the time that person will just watch the dashboard and nothing will happen. But when something goes wrong, it’s great to have someone else on your side.
Keen to try pair programming?
I hope that I was able to get you interested in pair programming!
If you want to get started, it really isn’t that complicated: next time you find yourself at any of the above activities, ask one of your colleages for help. Sit down together and work on the same thing, at the same time, in the same (virtual space). Keep it informal and short — that’s it.
Reflect on your new experience later that day. Have you learned anything? What worked well? What didn’t?
Next time I’ll share some of the typical problems and solutions I’ve encountered.