I get the impression that, in hardware companies, software is often not taken very seriously, when it can cripple the user experience for trivial bugs. It's also annoying that it's "proprietary" rather than open source, when hundreds of models will be using the same chipset in the same way. It's not a competitive advantage, the sleep code, it can only be a disadvantage if it's done badly.
2. Build hardware.
3. Oh, no! The hardware has a bug! We'll somehow fix it in software.
And fixes come only if there is an economic reason for doing so. As soon as the company starts developing the next product line, you're on your own.
Far too often, we have OEMs trying to build unique differentiating features without actually building much in the way of custom hardware, so you end up with some random thing hanging off GPIO pins or something like that, completely undocumented and driven by software that didn't really make it past proof of concept phase.
I had a desktop motherboard once that included a SATA power output intended to allow the software gimmick to fully power down hard drives you didn't need running. It was never worth the hassle.
I once used an HP laptop where the webcam disable switch was a USB HID device, and everything that connected that switch to the webcam functionality was implemented in software.
And then there are all the power management/tuning hacks written by people who've never even heard of control theory. Every "gaming" laptop ships with its own iteration on that disaster.
B) Look at salary for software engineer in semiconductor company then look at salary for software engineer at FAANG. Then ask where all the decent programmers are going to go.
This. I really wish I could be workikg in hardware, but the salary incentive is just there. Now I am stuck doing backend job to afford life and my low level and hardware hobby (reverse engineering games and firmwares, emulator, fpga stuffs), things that are magnitudes harder than making an api that put stuffs in DB and kafka