I sometimes lean toward calling it discriminatory, but generally don't - not because I think it isn't, but because I think that doing so weakens any legitimate criticism of the practice by coming across as hyperbolic.
My take: I like it as a training or mentoring activity. I like it as a voluntary activity for slowing down and being careful on trickier bits of code.
But I don't like it nearly so much as a mandatory thing. The social dynamics here are tricky. I'm a pretty severe introvert, and am quickly exhausted by what I experience as socially intense situations. I've been paired with exuberant, highly extraverted people, and the results were, frankly, disastrous. Within no time at all, I would be deliberately letting obvious bugs sail past just to avoid having to have interactions that I was finding to be increasingly mentally and emotionally taxing. And yet I'd still come out of it feeling so worn out that I'd be off my game for days. I guess you could say that that was negligent on my part, but, truth be told, once the cortisol levels in your bloodstream get high enough, you're just not thinking clearly anymore. And, in any case, it would be much easier for me to wait and put a more thoughtfully composed, "Hey, I just noticed..." comment in the async code review than it would to try and clearly verbally explain what I saw to someone who dislikes pauses in a conversation so much that they literally would not allow me 15 seconds to compose my thoughts.
So, don't call it discriminatory, but, still, it can easily end up making people upset and escalating intra-team tensions in return for not much. There's a term of art in some sects of Buddhism that I like to describe these sorts of well-intentioned but poorly executed plans: "Unskillful." Indiscriminately following a prefabricated, one-size-fits-all script often ends up being unskillful.
I think maybe it's a bit like test coverage. More code coverage is good, but, at the same time, I typically see the lowest quality test suites in codebases where it's been set up as an explicit performance metric and measured by some tool. Similarly, when doing Scrum-type-workflows, I find velocity to be a useful concept up until the exact moment when some manager finds out about it and asks for it to be included in a report, at which point it immediately becomes the most harmful thing ever.
That said, and for the sake of contradicting myself repeatedly, it sure is useful sometimes, and I'd hate to work at a place that isn't supportive of developers and teams who want to do it.
> Within no time at all, I would be deliberately letting obvious bugs sail past just to avoid having to have interactions that I was finding to be increasingly mentally and emotionally taxing.
This is 100% my experience. I don't do pair programming in any formal capacity, but do occasionally sit nearby while others write code.
I despise telling people they're screwing up at the rate they're screwing up in real time, especially when I'm more senior and they're just not noticing things that I see immediately.
Compounding this, I'm not great at quickly expressing myself verbally, and so it's not always clear what I'm pointing out. Even when I'm perfectly clear there's an element of a flustered typist trying to correct on the fly.
Combine this with introversion and mild social anxiety, and I'd say if my workplace instituted mandatory pairing I'd be looking for a new job the day they announced it.
My take: I like it as a training or mentoring activity. I like it as a voluntary activity for slowing down and being careful on trickier bits of code.
But I don't like it nearly so much as a mandatory thing. The social dynamics here are tricky. I'm a pretty severe introvert, and am quickly exhausted by what I experience as socially intense situations. I've been paired with exuberant, highly extraverted people, and the results were, frankly, disastrous. Within no time at all, I would be deliberately letting obvious bugs sail past just to avoid having to have interactions that I was finding to be increasingly mentally and emotionally taxing. And yet I'd still come out of it feeling so worn out that I'd be off my game for days. I guess you could say that that was negligent on my part, but, truth be told, once the cortisol levels in your bloodstream get high enough, you're just not thinking clearly anymore. And, in any case, it would be much easier for me to wait and put a more thoughtfully composed, "Hey, I just noticed..." comment in the async code review than it would to try and clearly verbally explain what I saw to someone who dislikes pauses in a conversation so much that they literally would not allow me 15 seconds to compose my thoughts.
So, don't call it discriminatory, but, still, it can easily end up making people upset and escalating intra-team tensions in return for not much. There's a term of art in some sects of Buddhism that I like to describe these sorts of well-intentioned but poorly executed plans: "Unskillful." Indiscriminately following a prefabricated, one-size-fits-all script often ends up being unskillful.
I think maybe it's a bit like test coverage. More code coverage is good, but, at the same time, I typically see the lowest quality test suites in codebases where it's been set up as an explicit performance metric and measured by some tool. Similarly, when doing Scrum-type-workflows, I find velocity to be a useful concept up until the exact moment when some manager finds out about it and asks for it to be included in a report, at which point it immediately becomes the most harmful thing ever.
That said, and for the sake of contradicting myself repeatedly, it sure is useful sometimes, and I'd hate to work at a place that isn't supportive of developers and teams who want to do it.