And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.
In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said:
> No, one person is doing things, and another is watching and talking while the other person is doing things.
I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.
In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.
> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other.
Apparently, pair programming places no value on flow.
> I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.
Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
> Apparently, pair programming places no value on flow.
There are certainly times where flow can be difficult. However I'll offer a few other thoughts.
Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.
I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).
> I just don't see how it's effective
I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:
- I am less easily distracted because I am in flow with someone else
- I am forced to consider my thoughts more carefully because I need to explain them to someone else
- I am confident that someone else can continue this work if I am unavailable
- I enjoy the camaraderie and friendships built with my pairs
- I quickly learn new tools, tricks and ideas from others
- I am able to practice my teaching or coaching skills
- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed
- I take more breaks throughout the day
- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature
- I'm likely to discover something I've missed with a different set of eyes
- I'm likely to take fewer shortcuts, or to be called up on them
- I've become a more effective verbal communicator in the rest of my life
Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
Fundamentally, if two people want to pair, and can meet their obligations as far as delivering work (produce two or more times the work than what's expected of an individual), then feel free. At the end of the day, I don't care how you do your work, any more than I'd dictate which IDE you use. The biggest concern that I'd have in a group with pair programmers is the noise from the constant talking, but most places don't care about having a quiet working environment these days.
However, with pretty much anything like this, just forcing it down everyone's throat is a recipe for disaster. Probably the most confusing thing about the original article was the statements "This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", followed by "It burned me out" and "I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management". Huh?
He realizes the powerful benefits of the technique, but he is an introvert and finds sustained social interaction tiring and stressful for his neurology.
> Apparently, pair programming places no value on flow.
For me, the hours zoom by like minutes. The end of the day is suddenly here, and I don't feel like I've worked at all. I was hanging out with a buddy chatting about stuff, and yet there is a pile of completed code in front of us.
> Apparently, pair programming places no value on flow.
I get flow with and without pairing.
I have ADHD, so for me flow is a spectrum from "smooth, effortless, light" to "destructive hyperfocus". Pairing almost completely prevented hyperfocus in my experience.
Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.
