First off - I feel terribly sorry for the author's experience and I can totally empathise to it. Also want to share my personal experience and some mitigation techniques.
I was pairing 8+ hours per day from 2012-2017 with 10+ engineers in total, most of that time fully remote. My company highly praised Pivotal and its processes, specifically pair-programming. Similar to the author, I have experienced different levels of engagement from my peers, conflicts, etc. I can 100% agree that pair-programming is extremely physically/mentally exhausting. Even just to talk for 8 hours/day puts your brain under extreme pressure. Here are some of techniques I've learnt and employed to mitigate the negative consequences:
* Talk through the pros and cons of pair programming with your new pair upfront. Ideally have your thoughts on the topic already written in a doc. E.g. clarify the difference between the dynamic: person behind the keyboard (driver) is generally thinking slower (spends time on typing), while the observer have more time to think. Explain the importance of switching the driver regularly. Explain the benefits of being the driver: e.g. if a person wants to build up the context in a new area it might make sense to be the driver and learn at slower pace. Ideally switch the driver every day.
* Agree on the scheduled regular breaks. E.g. I used to have a pomodoro timer for 45 mins and then a 10 mins break. When working from office having a game of ping-pong/pool is a great idea. When remotely just switch off from the computer to relax a bit. This also helps with distractions (e.g. Slack, Email, etc): use that time (and only that time) to manage the distractions so that you can have your full focus while pairing.
* Do frequent retrospectives and give feedback. At the end of the pairing day ask "What did you like/did not like?". Try to be honest: it is important to catch factors that irritate/annoy early and fix them rather than letting them grow into a bitter relation.
More importantly be inclusive: pair programming just doesn't work for everyone, there's no point to force someone in to it. It is worth a try though. I find its benefits hugely overweigh the downsides.
* Talk through the pros and cons of pair programming with your new pair upfront. Ideally have your thoughts on the topic already written in a doc. E.g. clarify the difference between the dynamic: person behind the keyboard (driver) is generally thinking slower (spends time on typing), while the observer have more time to think. Explain the importance of switching the driver regularly. Explain the benefits of being the driver: e.g. if a person wants to build up the context in a new area it might make sense to be the driver and learn at slower pace. Ideally switch the driver every day.
* Agree on the scheduled regular breaks. E.g. I used to have a pomodoro timer for 45 mins and then a 10 mins break. When working from office having a game of ping-pong/pool is a great idea. When remotely just switch off from the computer to relax a bit. This also helps with distractions (e.g. Slack, Email, etc): use that time (and only that time) to manage the distractions so that you can have your full focus while pairing.
* Do frequent retrospectives and give feedback. At the end of the pairing day ask "What did you like/did not like?". Try to be honest: it is important to catch factors that irritate/annoy early and fix them rather than letting them grow into a bitter relation.
More importantly be inclusive: pair programming just doesn't work for everyone, there's no point to force someone in to it. It is worth a try though. I find its benefits hugely overweigh the downsides.
edit: formatting