Who decided that programming was a lonely sport? An ode to pair programming
Hello all! I’m Carla, a backend engineer at Mercadona Tech. I work in the “Flota” team, where we are creating a system for managing the fleet of delivery trucks we have all across Spain. And, as every other team in Mercadona Tech, we work in pairs — which is what I’m here to talk about.
The wonders of pair programming have been proven over and over again by engineering teams; I won’t reiterate all of these. What I want to do is highlight the paradigm shift that pair programming could bring, and how it could change the perspective of the software engineering industry.
My introduction to pair programming
I remember when I found out that teams at Mercadona Tech work in pairs. It was during my interview, and I was surprised and excited. Finally! A place where writing code is a collaborative process, and where I won’t be alone in front of my IDE all day.
My interviewer was explaining to me why pairing was such a good practice, and I told them that they didn’t need to convince me — I knew.
Pair programming is far from being the industry norm, and when it is practiced, it’s often an exception. Something fun and different that engineers try out once in a while. In my previous teams, I was used to pairing when solving a complex issue, or needing to debug quickly. Or, even more rare, when a colleague also enjoyed pairing. But it was definitely not as a regular practice.
Friends working in other companies are intrigued when I say I work in pair programming. Once, a friend asked if they could pair with me to get a feel for what it was like.
I think this shows both that pairing is an exception, and that there is curiosity around it.
How did we get here?
Why did programming become the lonely sport that it (usually) is today?
Although the stereotype is fading, it was, for a while, the stereotype of the developer as a guy (yes, a guy) alone in a dimly lit room, hacking away on a black and green terminal. If this ever was the demographic, times have changed.
People from a diversity of backgrounds and experiences work as software engineers, and the idea of the bedroom hacker doesn’t fit many of us. We like to write code, but we don’t like doing it alone all the time!
For those of you who, like me, like to write code, and the idea of doing it together… enter the world of pair programming.
Busting pair programming myths for the skeptics
Although pairing is getting traction, software engineers understandably have their reservations about it. Let’s try to address some of these doubts.
“Pairing is a waste of time and effort. You could be doing twice as much work by working individually”
Rather than thinking that two engineers should produce 16 hours of work a day, think about the quality of the work and your experience writing it. When you work in pairs, you make conscious and informed decisions rather than implementing what first comes to your mind. You write more robust and maintainable code, and catch bugs and edge cases earlier. You get to know the entire code base, and why something is implemented a certain way. You save time and effort in the long run, by doing things better from the beginning.
“But that’s what code reviews are for”
Code reviews are an opportunity for engineers who didn’t work together, to give feedback and see code they didn’t write. But this is done almost exclusively off-line, with back and forth comments mostly about minor changes rather than in-depth discussion about the implementation approach. And be honest: how much do you actually invest in reviewing others’ code when you weren’t involved? When engineers work together, more care is put into writing the code that reaches production.
“I work better alone”
Some say they can’t focus when working with others, or complain they aren’t able to listen to music. Fair, I do miss listening to lofi beats. But pairing is an exercise that pushes you as an engineer. We all get a little too comfortable in our desk chairs and could do with being challenged once in a while. Being able to work with someone, express your ideas clearly, question an implementation, or answer doubts about your approach, all in real-time in front of your colleagues, are great skills to have.
Plus, many companies including Mercadona Tech interview for people who are able to work with others and explain their train of thought succintly. Pairing is fantastic way to practice for this!
Ok, I’m almost sold. What more is good about pairing?
You learn fast
What you don’t know how to do, you will learn from watching others. Or better, you will learn by doing, while they guide you. Vice versa, what others don’t know how to do, they will learn from you. It’s a collaborative and uplifting environment where you realise that there is no right way to do things. There are trade-offs and different creative solutions, and all opinions are welcomed and encouraged.
Hard tasks are made easier with the support of others
People bond by overcoming challenges together, and what better challenge than building an entire application? Or, spending hours debugging complex code? Pairing does wonders for team building, and this happens naturally and everyday. Engineers are always coming together, and not only at the end of a project to celebrate. Likewise, when you are stuck doing a kind of work you don’t love (for me, that would be implementing CI/CD pipelines) there is always someone there to support you.
No more imposter’s syndrome
You will be good at some things, other engineers in your team will be good at other things, and these things may or may not overlap. When pairing, you realise that no one knows it all. What is easy and obvious for you might not be to another person, and vice versa.
As an added bonus, the team has equal ownership of the entire codebase and all of the features. The culture is actually blameless, and when something goes wrong, fingers cannot be pointed. And when everything goes right, everyone wins.
What I really wanted to say was…
With lonely-programming being the industry norm, I didn’t think there was much of an alternative. But it doesn’t have to be this way!
The wonder of pairing is that you spend your time working with great colleagues, who are there because they also appreciate and seek this dynamic. It means you get to interact with your peers more than just in the daily stand-up, and really work together on building something good.
Pair programming shifted my perspective of software engineering. It showed me that code can be written together, and that code reviews could be a thing of the past.
Programming can be a team sport.
