I recently had one of these tedious discussions with a teammate. The person asked me for some help for implementing a feature, a RESTful API call to another service. Nothing big, nevertheless in an application that is untested, not really written in a clean code style and only runnable in a quite complex setup on a local machine. In my role as tech lead I see it as an important task to improve legacy code by — for example — adding tests when there is some work to do in this piece of code.
The simple reason is that I don’t want to take over responsibility for something where I can’t be sure that it works in all stages of the application. And, of course, I want to document the behavior of this particular code section with one or more meaningful tests for my teammates and myself (if I have to come back a few months later).
So far, so good. I was new in the team and in the company, there was no culture of testing (I’m not even talking about TDD) or pair programming. Everybody worked on their own, creating fancy pull requests that have to be reviewed by another member of the team. The funny thing is that I’ve been talking with this colleague about pair programming a few days ago, where he had a positive attitude towards this practice. But now, in this real-life situation, he immediately relapsed into the old, well-known argument:
Pair programming is nice, but I don’t have the time for that.
My first reaction was close to cutting up the table in front of me into several smaller pieces (which probably wouldn’t have helped). 🤬 This was one of the situations where I feel like discussing with people about the fact that gravity exists, but they don’t want to accept it.
So why do I and a lot of much smarter people than I think about pair programming as something very useful?
I’m not sure who invented the practice of pair programming. But I can say for sure that it is one of the cornerstones of the principles of extreme programming, which have been well explained in the book Extreme Programming Explained: Embrace Change by Kent Beck in 2004. Since then, pair programming and other methods have become more and more popular, especially when the agile trend started growing the past years.
Pair programming is fun!
One of the main reasons is: it’s fun. 👍 Yes. Really, believe me. In the beginning, it might feel a bit strange to sit together with a teammate in front of one computer, like a Microsoft Office course trainer and the old grandma who wants to learn how to write emails. I don’t want to go into the details of the different approaches of pair programming (one keyboard, two keyboards, remote pairing, etc.) — they all work well and have their pros and cons.
But the real benefit is something else: you’ll reduce errors.
Yeah! Isn’t that cool? I think it is! It’s such a satisfying feeling to push your code, garnished with some nice tests, wait until the CI/CD pipeline becomes green after a successful production deployment and go home with the good feeling: there was another pair of eyes checking our code (heads up: it’s our code; knowledge sharing, you know…). The danger of having overseen something is much smaller than it would have been if it was only one person working on the code.
Because the person makes mistakes (all of us make them, believe me). People have other things coming through their mind, they might not see a better way of programming this particular thing because they’re distracted: they might think about the sun, summer and a round trip with the kayak on the lake of Zurich.
A dangerous partner: the routine
Or I might write code in a way like I always did — something that is called routine. Routine is sometimes good and at the same time, sometimes very dangerous. During my career in the mountains, where I was training for the mountain guide education, I had a lot of situations where weird things and accidents happened because of routine. Not all of them went well.
In the maritime sector, there is a concept called Bridge Resource Management, where the captain isn’t the only guy who decides about maneuvers. The idea behind is the same: a four eye principle to make sure the bridge crew is involved in extensive decisions that might have a huge impact on the ship and the passengers.
What about the most famous factor, the time?
Does it really take less time to pull a request, dive into the code and the logic, understand what it does (I mean really understand, not just skim over the source code), get feedback from the author, correct something or ask the author to correct it — including all the communication issues that will happen, like „Oh, I always started working on something else, I’ll do that later“. Continuous deployment bye-bye.
And there’s another thing: the team factor. It’s a much better feeling when you know you implemented something together with your teammate. Celebrate it! 🎉 Okay, you shouldn’t open a bottle of wine for every user story, but you’ll find ways to celebrate that the story or the bug has been implemented. And that it’s done. 100%. Not only almost done. You know it and you can trust it, because you’ve written tests for it, you’re not the knowledge bottleneck and it has been successfully deployed to production. No waiting until someone has time to review your pull request, comes back to you after hours or even days with some improvement proposals — that’s an annoying prehistoric development style where frustration is guaranteed.
Pair programming for onboarding new team members
Have you ever spent time in a new team, figuring out what the hell this particular piece of code does, with no one around helping you or answer questions? Is that how you start motivated into a new job? Wouldn’t it be better (for the company and the learning curve of the new person) to have a pairing buddy to learn from him, with a shifting intensity of the keyboard usage? Not doing that is probably the best way to kill motivation effectively in the first days — and that’s for sure not the reason why you hired a new developer.
Why do I write all that? As you might have already noticed, I strongly believe in Extreme Programming practices. 😉 And pair programming is one of the cheapest steps towards XP practices, because you don’t need anything but a teammate. No new infrastructure, no CI/CD server, just someone else who sits next to you (or you go and sit next to someone — maybe he has a beautiful view on the lake outside).
Go try it out. And don’t be shy: some people are almost afraid of someone else being “better” then they’re — but that’s not the intention. Trust your pairing partner, help him and be open for help from the other side. Benefit from the experience of your partner and the other way round. The outcome will be a much better software quality, and that’s where your company will benefit from.