You're trying very hard to dismiss experience specific to a company and industry, but I'm not buying it. Someone who has intimate experience with an established code-base and the company will be vastly more proficient than a new employee of similar intellectual capability. It's why companies often try to hire people within similar industries and tech stacks to help reduce this gap.
It's like trying to argue that a mechanic who has only worked on Ford vehicles for 20 years should be able to quickly have the same proficiency as a mechanic who has 20 years of experience on only Porches. Nonsense.
Remember, a company can typically expect to hold onto a developer for maybe 3-5 years, so even half a year of training is a significant portion of their tenure.
But the status quo is already change and loss of expertise and teams and products continue along fine.
Also you maybe discounting the change in code itself even when I have years at a company I’m still continually learning things because I’m working on new things or new things are being built. If I left a new hire would be able to ramp up on these fresh code based without much hassle. So expertise itself has a half-life in a fast moving field like a lot of software shops.
>status quo is already change and loss of expertise and teams and products continue along fine.
Change in a way where past experience still translates to value. And yes, with enough money and brute force you can overcome the loss of tribal knowledge, but that's the whole point of this conversation; it's an expensive thing that's often not worth it and definitely not something easily dismissed.
It's like trying to argue that a mechanic who has only worked on Ford vehicles for 20 years should be able to quickly have the same proficiency as a mechanic who has 20 years of experience on only Porches. Nonsense.
Remember, a company can typically expect to hold onto a developer for maybe 3-5 years, so even half a year of training is a significant portion of their tenure.