I’ve always encourage pair programming solely as a team cross training exercise and only for short stints.
Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.
That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.
Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.
I like to use bringing someone up to speed as a vehicle for improving the documentation. Docs go stale and decay, and require regular maintenance. But without a fresh eye, you become blind to many of the problems the documentation has. Having a new person go through the docs, feel their pain, and fix the problems (with your help) is a golden opportunity to keep the docs fresh and usable, and more importantly codifies knowledge that can otherwise be lost when people leave.
Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.
That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.
Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.