Pair Programming Economics

I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.

I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.

----

Benefits of pair programming (IMHO):

* It eliminates the need for code review (most of the time) since another dev is providing input as you write.

* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.

* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."

* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)

* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.

* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.

Personally, I dislike PP

- hard for remote teams. Only good if everyone on the team can easily pair up.

- only good if everyone follows a strict schedule

- only good if everyone understands the problem and solution space equally. If one of us needs to go into a cave for an hr to read documentation or experiment, it all falls apart.

- very mentally intense. You're always on. Can only keep it up for a few hrs without some massive mental drainage.

Overall I like PP for small problems to help teach someone. I dislike it for day-to-day.

Through a lot of experimentation I found that pair programming can help in many cases: onboarding, code reviews, design & architecture and others (https://www.togetherwecode.com/articles/seven-ways-explore-p...).

It doesn't always work for me, but I found that it offers a surprising amount of benefits.

If you look at @programminggeek's point without passive-aggressive exaggeration and then at the wiki, you'll see that it's specifically called out as a potential problem.

Sadly, it's dismissed out of hand as a "people problem" and "irrelevant". It really deserves more attention.

First of all, if you're looking for programmers to maintain a VB6 app, you really should factor into the economics of that endeavor the fact that most people don't want to code in VB6.

Second, no matter how potentially beneficial the pair programming approach is, there is a question of psychology in play. There are people who are introverted enough that the constant company required for pair programming will wear them down and cause them to quit or change teams. Dismissing it as a "people issue" and misrepresenting it as being unable or unwilling to be a team player is an oversimplification.

Agreed. This has been my experience as well. I've mostly pair programmed over the last 15 years. Very similar schedule. Same pros & cons. There's a counter intuitive key element to Pair Programming - you're slowing down in order to go faster. You make fewer mistakes and correct them an order of magnitude faster when you do. You spend less time "thrashing" on something. You're less likely to loose the better part of an hour going down an implementation rabbit hole. Once you let get of the illusion that you can be better long term "by just going off and cranking this out on my own" (e.g. cowboy coding / hacking / JANGIT - Just Add New Garbage Ignore Testing), then the value of pairing really shines. 18 months into a project, you're looking at something that is still high quality, still manageable, and you still actually want to work on because you're proud of what you and your team have done.