I definitely learn things from people I don't expect to teach me anything. I'm used to pair programming being frustrating, but if you can put egos aside you pick up on different ways of thinking and way more exposure to life/programming experiences others have had. I think the shared office space is forced information exchange between people.
It's not comfortable, it's not necessarily conducive to YOUR methods - but you put enough interesting people in the same space and you're bound to jumpstart something. Maybe an HR incident, but something.
I actually am prevented from learning when I am forced to overhear exchanges between other teammates. Most of the exchanges are not relevant for me, often they are not discussing anything work-related as well.
It also swiss-cheese's my schedule, because instead of setting aside dedicated time for pair programming and for information exchanges or meetings, like you would think you should do in a professional workplace, those events are now thrust upon me even when I might be trying to finish some other work or I might have to urgently focus on something else.
The entire premise that continuous real-time audio is somehow synonymous with idea-sharing or collaboration is just insane.
Sincere collaboration is respectful of each individual's time and planned work schedule, as well as individual preferences for quiet, privacy, etc. Sincere collaboration can be asynchronous, textual, visual, or auditory (or a mix), can be remote-friendly, etc.
What you describe as "forced information exchange between people" is appropriate maybe for a trading floor or mission control, but the attempt to stylize a bullpen of software engineers in the same way is disaster, and at best it is superficial collaboration.
I definitely agree that it's a balancing act between "find the right person to pair with this other person" and "I can't get anything done, this person is only giving me irrelevant information". Often times it's just forced, and arguably not successful.
I meant that pair programming was often beneficial for me, and I work well with most partners.
It just has to be planned, put in a calendar item I can plan ahead for. If it’s constant pairing or if it’s ad hoc pairing that is thrown, unplanned, into my schedule, then it’s always a bad idea and makes both people worse off.
You also have to ensure the noise generated by pair programming doesn’t affect other workers who happen to sit nearby. They don’t benefit from my pair programming, and shouldn’t be forced to reduce their own productivity by putting on headphones, working from home, trying to find a conference room, etc. just because of my pairing session.
I found loss of autonomy and inability to use own brain completely killing my motivation. It might be fine with someone with high sociAl skills, but pair programming with someone who confuses own subjective preference with "objectively better" and have sever micromanagement tendencies is hell. And don't tell me that we should fire all bordeline autistic coders, I think we should cooperate in a way that does not make it hell to them nor to neurotypicals who work with them.
I don't think we should fire borderline autistic coders. I agree with you that it's not always the best approach to take to force coders to interact in a shared space. I used to enjoy something I had with a friend where we would watch git diffs and write back and forth to each other about the changes.
It's not comfortable, it's not necessarily conducive to YOUR methods - but you put enough interesting people in the same space and you're bound to jumpstart something. Maybe an HR incident, but something.