>There isn't as much pressure in tech to deliver low level results quickly.

I wish there was less over-generalised "Oh, these other guys, they've got it easy, unlike us!".

From my time in embedded, I've gathered some rather different experiences. Deadline are often tight, and as software integration and testing are by necessity the last step in the development process, it's always the software guys who're left holding the bag if anything goes wrong at the earlier stages of the project. The overall deadline must be kept, after all.

So when the hardware guys slip on their deadline (for whatever reason, it doesn't have to be their fault), it's of course up to the software guys to make up for the delay. How hard can a bit of embedded software be, after all? So you're left writing lot's of stuff on the dry, as without access to the hardware, you have no way to test everything in advance.

Then there's the cases where bugs in the layout or docs are only found after you insist forcefully that either the documentation or the hardware itself must be at fault (after hours of futilely hunting for a nonexistent software bug).

So, no, embedded is not necessarily as easy as some people like to make it out. As with most everything, it's very much a case of "it depends".

> There isn't as much pressure in tech to deliver low level results quickly.

This isn't my experience. Companies producing hardware or devices tend to think hardware-first. Any firmware or software that needs to be developed is often over-trivialised. The way management sees it is that driver/firmware development eats into profits, so it needs to be done quickly. "It's just software". I'd like to hear what stories other people have.

> Companies producing hardware or devices tend to think hardware-first

This was my experience. I worked as a firmware developer for a company producing computer hardware. The attitude of management was “the product is perfect then firmware breaks it”. Never mind that the thing didn’t work without firmware.

The concrete result was that it was impossible to get support from hardware teams. You would chase some weird bug for weeks, be ghosted by your supposed hardware support contact. Then finally chase the guy out to his car at 6:00 pm and find out, “oh yeah, we changed the address of that register, guess we forgot to update the software interface doc. I’ll update the errata tomorrow.” (obviously he never did).

"We'll fix it in software" was a common statement from management at an early job. It's a very frustrating thing, hilariously (or sadly?) they even put "will be waterproof" under the software requirements for one system. That was an actual mistake, but given the general theme of the place it was conceivable at first that it was deliberate.

In my experience, it depends wildly on how much of the special sauce is in hardware vs. software. Companies that work on mature technology (ex. ECG) but have to continuously improve the signal processing tend to view software as the hard part. Companies where you're building fundamentally new hardware tend to view software as the trivial part.

Interesting counter-point about companies where low-level software is user-facing. Embedded systems probably would be another one. I was talking more about the software tech, closer to "big tech".

This is in line with my experience of lower pay offers for embedded SW development compared to business applications.

A lot of the points also seem to apply to algorithms or mathematical programming, just because the libraries do what you expect and mathematics isn't messy the way web framework du jour is. At least until you get to tweaks that seem to work but there are no good proven bounds for their performance.