Pair Programming: The Good, The Bad, and The Ugly
When I started at my first dev job, there was only one way to program: Put your head down and write code. Every so often, I would collaborate with a team member for short bursts, but coding typically happened on my own using my own machine.
Then I found out about a company that boasted that it did 100% “Pair Programming.” What is pair programming? Pair programming is when two people sit at one machine and code together on the same problem. It’s like the collaborations that I was talking about earlier, but instead of being the exception, it was the norm. It was a concept that intrigued me.
I later found out that that statement wasn’t accurate, but why it wasn’t was because this company didn’t just practice pair programming, it also practiced what is called mobbing. Mobbing is just like pairing, except for instead of just two individuals, you would have 3+ people all working together on the problem. Code review, typically in the form of a pull request, did exist as well but they are typically a small minority.
Why would a company advocate to work this way? What are the advantages it gives? As I researched it more I found articles and studies that boasted of the benefits of paired programming, but they all pretty much came down to one major reason: It results in fewer bugs that make it to production. The theory…
