The tooling and the culture in the software world is decades ahead of fields like engineering or business management.
Take ideas like version control - a way to do change management. Open source. Test driven development. Continuous integration. These have existed in a nascent way in other fields, but software engineering has really taken the ideas to the next level.
I know some new hardware companies that have taken these approaches to their whole integrated hardware-software development methodology, with extreme success.
So it seems we need new car companies in Europe, and at least one founder probably needs to have used git.
TBF version control started (SCCS, RCS etc) by modeling how version control was done in mechanical engineering and architecture. Just look at the manual version control in old blueprints. Nowadays CAD systems like solidworks have a VCS for your models too. Absolute shit based on proprietary MS file formats, but it is there and it works.
OTOH there are reasons why you can't do TDD in the physical engineering, much less CI. When you're building a bridge you have to do FEA on your design, but the cost committment of construction doesn't allow much incremental change as you go -- almost all is in response to problems found once you've started building.
Code review is inherited from practices of other engineering disciplines.
I once mentioned this meme (referring to a specific anecdote) in a small group of CS people, and the big-name CS professor in the group immediately agreed with it, saying "They are our worst enemy!" (I think he was referring, seriously, to everything that has been learned, in his fields of CS and Software Engineering, beyond what needs to be exercised to get a program to compile and initially seem to work.)
My theory about that meme: all EEs (for example) will have done some programming (in some cases, like someone who can write numerous paragraphs of English, but isn't even aware of the gap between that and a great novel). And EEs might also reasonably have the impression that "coding" is easier than the hard real engineering classes that the EE had to pass. Of course, it's clear to everyone that CS people couldn't do the jobs of EE people, but it's less clear in the other direction.
To the extent that the meme is sometimes true, I think current market realities don't break it. A company driven by people with hard engineering/science backgrounds might realize it has to pay some market rate for software people. (And if the product obviously needed some kind of clown college skills, like face-painting, they'd pay for it, even if they thought those clowns had it easy.) But that doesn't mean they understand what's involved in the craft of effective software engineering, nor respect what goes into software staff's processes and judgment.
This isn't only about hardware and software people. I think it might be a more general human problem, across disciplines. It makes sense that software people will most notice the version in which they're on a receiving end, which I'd guess is usually on the other end of hardware people or (like most everyone else) business people.
(Additional theory: if an organization doesn't understand and respect some skillset, they might not be able to discern strong candidates when hiring for roles needing that skillset, and random results could be self-reinforcing.)
Of course a meme isn't truth, and it can be unfair to individuals. And some of the best software work I've seen was by people with EE/CE/math/no degrees, and I was also blessed early in career by working with great hardware engineers who did respect software.