These are common and, I think, reasonable objections. Particularly for someone who's actually done it. I work for a company - Pivotal - that relies on all-day

These are common and, I think, reasonable objections. Particularly for someone who's actually done it. I work for a company - Pivotal - that relies on all-day pairing. # Tiring I agree that it is tiring. We take breaks, as many as folks need. I tend to introvert and I spend time alone during lunch to recharge. That said, it became more normal after a while. It does for most folk. # Configs and Ableism I didn't experience the config-by-committee thing. Each pair, each team uses whatever they want. There are common configs around, but you don't have to use them. If you do, it's mostly because they're helpful and commonly installed. My pairs have always accepted accommodations for my own needs. For example, a symptom of my ADHD-PI is dyspraxia. Stupid hands. So I need much lower mouse sensitivity or I will have an infuriating time overshooting everything. When my peers pair with me they turn it down. When they pair without me they turn it up. Nobody really gets twisted up about it. If I paired with someone asking to bump the font, I don't mind. Colour-blind? Jetbrains have a checkbox for it! Being empathetic is part of being a good pair. It's harder than it looks. # Learning I agree and disagree. I think that saying that pairing is the best way to learn all things is obviously wrong, bordering on strawman. But it's a great way to learn a lot of things. It's a great way to see examples of practices, to have examples explained, to learn the quirky, hard-to-describe-in-docs gotchas that someone with more experience has already encountered for you. On the other hand, sometimes it's better to rip through a pile of reading. Even if you come out completely wrong, you come out with some kind of skeletal understanding, on which pairing can quickly build. I've argued internally that a key difference is in how easily something is diffused. Some lessons, knowledge and behaviour are highly diffusable; some are not. TDD, for example, is very quickly and effectively diffused by pairing. Stack-specific knowledge is diffused at a reasonable clip, but works best with skeletal knowledge. Unobservables or topics with long feedback loops require different approaches. In these situations you turn to books and training as a prelude to having that knowledge refreshed and supported by pairing. I have both observed and been responsible for "watch the master". Locally we call it "Bulldozing". I used to do it without thinking about it. It sometimes still happens. It is still incumbent on me, the bulldozer, to be aware of that. I have had discussions with pairs of the form: do you mind if I bulldoze for a bit? Sometimes they're cool with it and we're off to the races. But again, if they ask to slow down, we slow down. It's pair programming. I am working with someone, so if either of us wants to change the dynamic, we talk it out briefly. In that same vein, I've been in situations where I am exhausted and struggling for inspiration. I'll say, "do you mind driving a bit more today?", and usually that's fine. Often after a while I begin to tune in more and the dynamic shifts, organically, to a give-and-take. But it is also up to me to stop my pair if I don't understand what she or he is doing. I do this a lot. It's welcomed because we don't want to fall into future master-watching / bulldozing situations. At Pivotal we constantly discuss this stuff, constantly argue different approaches and constantly experiment with it. Right now, for example, I am on an "odd" team, meaning someone is soloing each day. I find that a solo day now and then is a good change of pace and lets me do deep-diving and sploshing around. But I also find that I am less effective as a 100% soloer. I go down rabbit holes. I make simple errors. I get stuck on something that might be obvious to someone next to me. I form elaborate theories that get punctuated by simple questions. I begin to draft The Last Code We'll Ever Need, before realising I'm just trying to get a simple task accomplished. # Pairing in general Most people who criticise pairing haven't tried it a) with someone experienced in pairing, b) for more than an afternoon. When people come to pair with us in Pivotal Labs, they are often skeptical and it often takes a few weeks for pairing to click and seem like a good idea. Sometimes it just doesn't. Which is good. No practice is for everyone. But I also want to point out that my experience, the experience of my peers, the experience of many of our clients, is overwhelmingly positive. We are not preaching this from a book. We're doing it. # Cult Beck I once introduced a talk by Kent Beck. In the lead up, I told him that the first time I read his TDD book, I thought it was total horseshit. He laughed. In the talk he started with the story of how nobody attended a talk he gave when he was new at Facebook (but the cooking class next door was full). As cult leaders go, he has a talent for deflating his own ego.