I don't agree because a large part of competency is choosing the right tool for the right job.
It's like giving Novak Djokovic a hammer instead of a racket and still expecting him to win tennis tournaments.
I bet he invests a lot of thought and effort into selecting his racket, his shoes, his clothes, his food, his coach, his sponsors, his medications, his strategies... Without the ability to choose his tools and techniques, he would be nothing.
... And yet that's exactly what we expect from developers.
If you're advocating for tool fetishizing and rewriting things by chasing hype cycles, then that is part of the problem.
The world is awash in half baked tools that are extremely popular until people somehow collectively realize it's a waste of time.
The frenzied mania of mobs shifting from framework to framework every 6 months is like the world of top40 radio brought to programming; relentlessly promoted crap that just disappears silently to be replaced by more irritating crap with a different version of the same problems because there's always a new generation of teenaged programmers who think they've fixed everything.
The people who follow and fall for it are part of the trainwreck programmers I'm talking about.
Really I want to stop the burnout and churn of the industry. I strongly believe the decrease in quality is because senior people tend to exit. We're 45 years into the microcomputer revolution and 65 or so years into career programming yet whenever I go to a startup, conference or meetup, the "in industry < 5 years" outnumber the old by a significant margin (except for sysadmin stuff).
It's an intrinsic cultural disposition that reinforces itself and we're going to continue to be stuck in this interregnum until we can somehow unmoor ourselves, collectively, from it.
I think a cessation of tool fetishizing and substitution with tool skepticism will help.
There's a bunch of them. I'm opinionated on physical real world actual concrete versioned implementations, not theoretical amorphous relationships existing in pure thought stuff, which is how a lot of these projects "documentation" is written - as if the code lives in abstraction like some improvised jazz scatting.
That practice is pure cult bullshit.
But yes, plenty of orms are fine, as long as it's a convenience. It has to empower the user, not just set up blockades in order to adhere to some ideological purity. That's once again, cult nonsense
It's like giving Novak Djokovic a hammer instead of a racket and still expecting him to win tennis tournaments.
I bet he invests a lot of thought and effort into selecting his racket, his shoes, his clothes, his food, his coach, his sponsors, his medications, his strategies... Without the ability to choose his tools and techniques, he would be nothing.
... And yet that's exactly what we expect from developers.