>
Performing the task of weightlifting is incredibly different than performing the task of programming.My point was that coaching is coaching. Fast feedback is more effective on great many learning tasks than slow feedback. It's why we obsess over closing loops.
> At the very least, this is more highly true of introverted personality styles, and creating mandates for policies like pair programming is extremely insensitive (almost to a point of blatant discrimination) towards people with differing personality and learning styles.
We discuss this question a lot internally. Speaking for myself, I don't participate in most of the social activities happening in and around the office -- I want alone time to recharge.
Sensitivity to others -- empathy -- is one of our core values. It has to be. We're collaborators. We're learners and teachers. We have to think about our pair, we have to be sensitive to their rhythms and limits.
That said, there's a self-selection process too. Lots of people either read the job description and nope their way out, or go through a pairing interview and nope out.
> I have to read documentation or code.
We discuss this too. It's perfectly acceptable for a pair to agree to split up and read docs.
> I suppose I serve as something of a counter-example, then. Just because beginners in weightlifting (or any given activity) benefit most from fast, in-person feedback does not at all mean that beginners in some other activity (like programming) will also benefit from that kind of feedback.
Some feedback is fast. Some is slow. Pairing allows for both. Asynchronous code reviews do not, especially since the incentives are whacky. I've seen a few such systems at different companies now and there are common antipatterns: for example, tiny patches getting the nod quickly -- but anything more than a bit tricky languishing for days or weeks, becoming stale. Codebases dispersed across forks and branches and patches; enormous fleets of patches in flight and no way to test the permutations.
> In both cases, across the board, pairing slowed us down and led to worker dissatisfaction.
Since we're trading anecdotes: I've never seen this. Ever.
I've been working this way continuously for two years now, with developers from multiple companies in multiple industries with varying levels of experience, wildly varying cultures and power structures and cultures and procedures and pain points. The uniform win has been pair programming -- even with developers who came in promising that they'd hate it.
> If the exact questions and answers that were discussed during pairing had instead been turned into an internal StackOverflow and/or an internal quick start guide, it would have helped far more people get up to speed far more quickly than pairing
There's nothing about pairing that precludes internal Q&A (we have that, informally and formally) or writing documentation (a good README is gold).
> Pairing is the definition of an activity that doesn't scale
There are more than 120 engineers pairing on Cloud Foundry now, spread across multiple offices on multiple continents in multiple teams. And we're hiring. And so are other Cloud Foundry Foundation members.
We scaled it. There were definite growing pains and we've had to eat humble pie garnished with crow a few times. But it scales in the same way you scale any other project. Better, in some ways, because engineers rotate between teams and carry deep insight of distant codebases to their new teams.
The thing is that two years ago, I would've agreed with you. I took my job in Pivotal Labs because I wanted to learn and I was prepared to hold my nose.
Now I'm an extremely annoying proselyte. Converts often are.
I understand that you don't feel the same and that you probably never will. That's OK; it's a big industry and different people can find the way to work that suits them best. I just wanted to put the case that pair programming is, on my fulltime, professional experience of the past two years, fucking awesome.