I used to be a zealot. I had found the religion of XP, and I enforced pairing on teams I was hired to coach. Many people were happy to be exposed to it, but many weren’t. Of those, some were better for the experience, some weren’t. In either case, it was massively disrespectful of me to force it on people. Certain kinds of people are drawn to programming. Asking some of those people to pair all day every day is tantamount to asking them to switch careers. I for one don’t have the emotional energy for it any more. Having said all that, I would encourage any skeptics to give it a try, in the right environment with the right teammates. It can really teach you a lot in a short period of time.
I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I <i>really</i> miss pairing.<p>I feel that most of the problems my team has now would be easily solved by pairing. Things like shared standards (not just syntax but architectural approaches that are hard to automate), testing (you keep each other honest), and faster code review. Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. People don't have a good idea what anyone else is working on (beyond the few that seem to do most of the code reviews). Swapping pairs every day or two easily solves these problems.<p>Things like on boarding new employees is just <i>so much faster</i> that it's a no brainer to pair, especially when they're starting out. Junior developers learn <i>so much faster</i> by working directly with a senior developer. Sure, it might slow the senior down (very little in my experience) but it makes the junior developer so much more productive in the long run.<p>Pairing is mentally exhausting at first and I can understand that it isn't for everyone. Most people hate it at first, especially if they have a bad setup. Most people I work with seem to think it means 2 people crowded around a single laptop. Setting up real pairing station with multiple BIG monitors and 2 keyboards and mice is crucial. After you get comfortable with it, the "always on" feeling goes away and it just becomes an enjoyable day working closely with your colleagues. If you really give it time, I feel it's the "right" way to develop software.<p>Switching a team to pairing might not be the right decision for everyone. Some people are just uncomfortable working with others. I'm not sure those people will be super strong members of most teams anyway, but they can certainly be successful in some organizations. If you build your team around pairing and select for it in your interview process, you can have really great results.
I find pairing with anyone that is significantly outside the range of your competency level, to be extremely frustrating.<p>You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile.<p>IMO - pair programming is over-hyped. I often find that I produce better, more reliable code, with the more space and more time I am given. I agree that pair-programming can rock in certain circumstances - but you need developers that have a certain level of synergy, you can't force it.
I started with XP way back in 99 after following the discussions on OTUG and then the white book came out.<p>I PP for 8 -> 9 years. Theres a bunch of things I learnt from that<p>It is really good for improving everyones skills. There is a fast convergence in good way to do things<p>The code quality is generally really good and people often develop good habits, everything gets discussed.<p>It doesn't work so well when people are across different projects, much better if they are all on the same project.<p>Teams reach a point where it doesn't actually matter if you pair or not, you tend to carry on making good code.<p>It can slow down experienced devs and they often don't get the same kind of "flow / mental zone" of coding they can get by themselves.<p>Developers need alone time to do their own coding experiments and to follow their own noses<p>It 100% has to be done right and people need to be open to the idea, I went into other companies who were trying to do it and it was failing massively. There was animosity and a lack of openness to trying it. People really didn't understand why they should do it, and felt coerced and threatened by it all. Untangling those messes seemed ... unproductive :)<p>It's exhausting.<p>These days I don't see the need for full time pairing, I see it more as a tool that has certain outcomes, and you use that tool when you notice certain kinds of problems / weaknesses. I would think that teams should "pair" at some point, and by that I mean watch each other code and have interactive discussion about code as it gets developed.
Pairing with someone you get along with is a great experience. But with a lot of people I find it pretty miserable. I have paired with people who I just almost never agreed with. I am not saying they were bad but I just didn't like their style. There is also the risk of having one very dominant partner and the other one just watching passively (or having checked out already).
The "How to pair with a junior developer" section is extremely considerate, and highlights some behaviours that I know I've subconsciously engaged in that may have negatively impacted a junior dev. Expanding this section would be great.
For contrast, here is an article I wrote that is largely against pair programming: <a href="http://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/" rel="nofollow">http://www.mattgreer.org/articles/pair-programming-is-not-a-...</a>
We got rid of the bad breath, smelly ass, coffee spill issues associated with pair programming. It's all remote now using VSCode Live Share and something like BlueJeans or Slack calls to facilitate the communication.
<a href="https://books.google.ca/books/about/Pair_Programming_Illuminated.html?id=LRQhdlrKNE8C" rel="nofollow">https://books.google.ca/books/about/Pair_Programming_Illumin...</a> << Pair Programming illuminated shows all the different kinds of combinations that are possible between programmers of different abilities and experience
How well pairing works also depends on a person's personality. Introverts don't really do well in pairing situations, and especially when paired with someone totally opposite, the pairing essentially becomes a single person coding and the other person just observing and nodding their heads.