Agreed, and that's why I mentioned I think you shouldn't just silo yourself. That doesn't seem to work either. I don't really have a good answer or alternative, more just pointing out how the dynamics of team based software development seem to be optimized towards burning out programmers. I don't know how to fix it, but it seems to be a problem.

A first step is probably treating your developers skilled specialists (hopefully you've hired a good team, of course), and not just code monkeys who have to show their manager a progress report every single day.

You do know how to fix it - you don't loop in others until you want to.

The problem is our industry, forcing developers to exhaust their energy on pair programming in open offices. May as well be in a daycare center with children all around.

Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.

Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.

I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.

Each tool has its use case. Forced use results in misuse.

I actually found it quite helpful, not just for getting up to speed. After moving to another division of that company that didn't employ full-time pair programming, I saw code of noticeably lower quality being produced. That said, it was emotionally exhausting for me to do full-time pairing and I'm not sure I'd go back to it.