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.
I've seen the following from pairing Junior and Senior engineers:
* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.
* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.
Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years.
Hiring for pairing is important. It's not for everyone, although not everyone has been in an environment where it's done well. I make sure to let people know they will be pairing full time on my teams and ask if they are comfortable with that. Also won't hire anyone that would be significantly slow to work with (can't touch type, slow thought process)
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.