My team does pair programming on >80% of all production code and has done so for the entire 18 years this product has been around. From entry level to architect

My team does pair programming on >80% of all production code and has done so for the entire 18 years this product has been around. From entry level to architect, we find that pairing is the best way to reduce defects, get more features, and knock down silos. While it has downsides around keeping a coherent architecture and hiring, we're now the market leader in our niche and are holding fast. Meanwhile many competitors come and go as they buckle under the weight of the immense complexity of the domain. I think for large and complex domains, it allows us a competitive advantage as our developer costs stay lower due to rapid onboarding and rapid growth of individuals. Very quickly our team members rise to the average skill of the whole team. We're a small team, and yet stay very effective as an aggregate over long time spans. Also the quality of the codebase stays extremely high, with very high test coverage and a robust CI process. I consider pairing as another tool in the shed for dealing with large complex domains just like strong static typing, a good type system with union types and no nulls, static analysis, and unit testing. These are all impossible see if they impact productivity because software productivity is unmeasurable. However, I'd want all of them as competitive advantages in a large and complex domain. Plenty of people reasonably debate their value, but many domains aren't complex enough to warrant the extra costs. I'd expect that if we were doing standard CRUD work, it would be overkill vs just throwing more bodies at the problem, but CRUD is a relatively small part of our product (large bank financial analysis and workflow) We also do: - reading clubs - weekly 10% self-directed and dedicated research time - additional research time with sign-off from a lead