(author here) Good points, I wonder if at this point I'm just saying "software development is software development!" I do think there are a lot of similaritie

(author here) Good points, I wonder if at this point I'm just saying "software development is software development!" I do think there are a lot of similarities in building the run-of-the-mill "sensors + actors + orchestrator + UI" embedded system, deploying and monitoring it. Which I must admit is most of the system I have built over the years, some had an expansive IoT/Connectivity component, some of them didn't. After handling the low-level peripherals, I find that a lot of time is spent on say, properly handing UI workflows, be it in react or with an ad-hoc push-button / encoder / character LCD setup. Or say, doing a RPC + streaming data exchange over USB. The point I'm trying to make, and that I might expand on in more details, is that for people outside the field (mostly on the web side, of course), it might not be apparent that: "you know that USB is kind of websockets + polling HTTP?". Hopefully that leads more people to do embedded development beyond arduino and micropython (which are great, and honestly my first prototyping choice). Another common task in embedded systems: writing a driver. Most drivers I wrote are "look up the kernel API, look up the device datasheet, write the glue", which I find very close to "look up $service1 API, lookup $service2 API, write the glue". There's subtlety on the one side in how to say, deal with priorities and deferred tasks and userland locking, but that subtlety is very much present on the other side too, with retries, idempotency, latency, event loss, etc... To me again, a lot of similarities, and I will use the same kind of techniques (mocking so I can mostly develop in userland / localhost, instrumenting tricks, etc...) Writing an OS (or, in general, building the underlying frameworks and tooling, like say writing a database engine) is a pretty rare thing.