It's gotten better over the years, but there are still huge misunderstandings and misvaluations of the different work. Obviously a hardware system needs hardware engineers, but nearly every hardware system these days involves software systems that do the actual work of coordination, communication, and control. It can't be treated as an afterthought but it often is.
From my perspective a lot of that is because the tooling and mindset for hardware is stuck in 1980s/90s. Compared to modern software development, there is very little to no automation in hardware design.
Things like CI for hardware designs and even automated version control are just starting to become a thing in the embedded space. Automation like building Bill of Materials, build pdfs, gerbers are not in any way optimized.
Scaling embedded stuff (design, manufacture, etc.) is very much a linear thing today, which is why salaries are low.
On the electronics side, better modules like RPi's compute module, open source footprint libraries, and reference designs have significantly sped up development since I started twenty years ago. What used to take weeks or months in Altium can now be measured in days, especially if companies publish their reference designs in the application format instead of PDF. The turn around time and cost on PCBs have also dropped precipitously, to speak nothing of the turn key assembly that the fabs offer. Pretty much the only thing that has stayed the same is that MetCal induction soldering irons are still the best.
On the mechanics side, it's hard to appreciate just how much better vendors' CAD libraries have become, to the point where you can drag and drop Misumi/Mcmaster/etc parts from a Solidworks extension onto your assembly like it was Gary's Mod. 3D printing alone has made everything more efficient during development and has enabled many interesting production designs from rocket nozzles to turbojet engines.
Prima donnas? What a twit.
I wrote nothing about having software "calling the shots" (I assume that's who you mean as "prima donnas"), but when software is essential to your system, you should have that team at the table in your planning and budgeting efforts. If not, you'll get poor quality because it's low priority. And you'll get poor quality if you reliably underpay people, the good ones leave.
I like to tell them that software should be on the BoM even though the marginal cost in $0.00. Having it noted as a component helps get people on board with proper versioning, and also raises visibility for something otherwise unseen.
Pulling together working hardware, packaging, and logistics is non-trivial, often involves multiple people, many moving pieces, extended chunks of time, and heroic efforts to resolve the inevitable problems. When the hardware comes together, it is only after a valiant team effort and at some cost. Everyone knows how hard it was. By comparison, firmware is invisible, usually written by fewer (or one) people, and usually carries lower risk. If your firmware has a bug two weeks before shipping, it's a recompile and we're back on track. If your hardware has a bug two weeks before shipping, it might be the end of the organization.
With hardware, it's the physical 'thing' that is the product. With applications, it's the software itself that is the valuable thing.
These comments leave me confused. My Michigan based understanding would have you both poorly paid for embedded work and obscenely paid for backend work. I know some folks in CA make 200K and up, I'm just not sure how common that is. And anyone doing embedded should be at least 100K, so I don't see an easy x4.
I am a pure embedded sw. guy (3 YOE) and have already started to learn DB management and higher-level languages (Java and C#). How was your transition?
I disagree. At my workplace(regulated industry), Embedded software engineers are paid 2x-5x of other engineering groups. Infact, some of our embedded engineers have so much leverage that they have negotiated 3-4 day work-weeks. Second highest paid group are DevOps(though they don't actually do much for us, as there is separate IT department). And our generic software engineers for web and custom-devices also make decent salary. What you mention could be a US centric thing.
Just to make some sense, our embedded software engineers not only write good code, they also maintain their own CI/CD, extensive test coverage, harsh code reviews, very well maintained codebase(unlike on other places I have worked where arcane header files are thrown around and used, no questions asked), automated deployment and update system, A/B testing, rollback and other interesting things typically practiced by higher level(web/desktop/mobile etc.) engineers.
I have also worked at a big name AG where they make specialized hardware, the engineers there also made very decent pay but quality of software and development practices were more like script kiddies copy pasting things and calling it a day if the emulator showed correct operation.
Almost all of my ex-colleagues went to web dev/fin tech :(