| 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. |
* 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.