TL;DR
Pair programming is not a zero-sum game. It’s not a simple equation of person-hours spent vs. code created. Pair programming produces more than twice the value for the extra bandwidth spent. It improves work quality and offers unexpected benefits.
Pair Programming Doesn't Make Sense...
By my third software engineering role, I hadn't heard of pair programming as more than a suggestion for what to do when you got stuck on a problem and needed help. Coding had been collaborative, sure, but individual tasks had always been something I worked on alone.
I'd think about a problem, program my solution (maybe even get into "the zone"), and get feedback at the end from more experienced engineers. Like many, I had to learn how to ask for help when I needed it. Even honing that skill, though, didn't prepare me for pair programming as a practice.
A year ago, when my manager told me we'd be pairing consistently as a team, I didn't fully understand.
"Oh, like syncing more on tasks before code reviews?", I asked confused.
"No, coding together as a baseline. Two engineers to every task.", he responded.
It sounded as backwards as it possibly could have. I had always prided coding as a silo of productive zen. Give me a computer, some headphones, and a couple of solid hours to solve a backend problem or create an exciting UI feature and I'd be a happy camper.
When I thought of a software engineer at the peak of their creativity, I pictured just that: a software engineer, at the peak of their creativity. Until that day, I hadn't realized how personal I considered the act of programming. How could my manager suggest, no expect, that I bring someone else into my coding time?
—Wait a second. Someone else butting into my creative flow aside, how could having two engineers on the same task possibly be more productive than just one?! Surely there was a mistake.
My manager was literally suggesting we cut our productivity in half. Two engineers spending twice the person-hours on the same coding task couldn't possibly speed through that task fast enough to make up the difference. Surely, two people to a task would introduce extra overhead that would slow down the process somewhat. Forget the lost solo coding time, pair programming didn't even make mathematical sense.
I didn't know it, but I was falling into the same logical holes as countless others had when first introduced to pair programming. Over the last two years, I've come to realize that my instinctual argument against pairing came from a misunderstanding of its purpose.
I saw programming as a simple input and output: I put my hours in and code came out of the other side. When someone suggested putting twice the hours in for the same result, it broke my equation.
I was missing something. In fact, I was missing several somethings. The true purpose of pair programming would fill in those missing somethings.
... Because It's Not A Zero-Sum Game
A zero-sum game is a situation in which the total gains and the total costs of a decision add up to zero. I viewed software development through this lens. The time I put into coding (the cost) equaled the code produced plus a little knowledge-gain on my part.
Pair programming results in more than sum of the time put into it. It is not a zero-sum game.
Working in conjunction with another developer produces intangible benefits that represent an exponential return on investment for both developers involved. They far outstrip the time cost associated with two team members working on the same problem.
The Exponential Returns of Pair-Programming
There are a number of benefits to working in pairs that can actually increase your coding speed and make your life easier. Here are a few major ones that I discovered in my experience:
- Knowledge-sharing: When you work with another developer, you have the opportunity to learn from their experience and expertise. They may have knowledge of a programming language or framework that you're not familiar with, or they may have a different approach to problem-solving that you haven't considered. By working together, you can share your knowledge and learn from each other, ultimately leading to a better end product.
- Team building: Pair programming can be a great way to build camaraderie with your colleagues. When you work closely with someone else, you have the opportunity to get to know them on a personal level. This can lead to better communication and collaboration in the future, as you develop a stronger sense of trust and mutual respect.
- Mentorship: If you're a junior developer, pair programming can be an invaluable tool for learning from more experienced developers. By working closely with a mentor, you can receive feedback on your code and learn best practices for coding and debugging. This can help you develop your skills and become a better developer in the long run.
- Collaboration: When you work in pairs, you have the opportunity to bounce ideas off each other and come up with creative solutions to problems. This can be particularly helpful when you're stuck on a difficult bug or trying to come up with an elegant solution to a complex problem. By working together, you can leverage each other's strengths and come up with a better solution than you would have on your own.
- Catch bugs faster: Two sets of eyes are better than one when it comes to catching bugs. By working together, you can catch errors and fix them more quickly than you would on your own.
- Write better code: By sharing your knowledge and collaborating on solutions, you can write better code that's more efficient, maintainable, and scalable.
- Get more done: When you work in pairs, you can divide up tasks and work on them simultaneously, getting more done in less time.
- Reduce the risk of burnout: Pair programming can be a fun and engaging way to work on a problem. By working together, you can reduce the risk of burnout and keep each other motivated and engaged.
So, there you have it. Pair programming is not a zero-sum game. By working with another developer, you can reap a host of benefits that can ultimately lead to a better end product. So next time you're stuck on a problem, consider pairing up with a colleague and see what you can accomplish together.
Top comments (2)
One aspect of knowledge sharing / bug catching that you missed is that when the code is eventually pushed, you now have two+ engineers that intimately understand how that code works and why it was written that way. This likely speeds up future enhancements and bug fixing, as well as also helping to prevent knowledge silos.
Yet to be convinced. Tried a number of times... huge productivity killer, awkward, causes arguments, not remotely fun, etc.