Software really has inadequate training. People get very diverse training experiences and that can be a source of friction between developers at different qualities and competencies.
It also moves so quickly that things don't settle and people have time to get intimate with frameworks and paradigms - I'm talking like 5 year timelines with libraries doing only maintenance updates. Front-end was bad for this because of the browser wars and JS's foundations gave it a really rocky start. The allure of starting over with a new library to get away from the current "bad" way of doing things is often repeated: SPA frameworks over vanilla/jQuery sites, hooks, and now maybe signals?
There are also jobs asking you to be spread very thin among things, while keeping deadlines, so you end up googling around to get it to work, even if it violates some principles of the frameworks you're using. That doesn't really lead to expertise.
Yeah: I remember drawing boxes and arrows in CS61A at UC Berkeley when learning about closures, but not everyone I work with took that class, remembers that stuff, or was taught it in the first place. Very few people can on-the-job Google to learn a mental model that takes undergrads a few weeks of diligent practice.
It also moves so quickly that things don't settle and people have time to get intimate with frameworks and paradigms - I'm talking like 5 year timelines with libraries doing only maintenance updates. Front-end was bad for this because of the browser wars and JS's foundations gave it a really rocky start. The allure of starting over with a new library to get away from the current "bad" way of doing things is often repeated: SPA frameworks over vanilla/jQuery sites, hooks, and now maybe signals?
There are also jobs asking you to be spread very thin among things, while keeping deadlines, so you end up googling around to get it to work, even if it violates some principles of the frameworks you're using. That doesn't really lead to expertise.