I am not sure which particular flavor of "embedded" the author is referring to, but the argument, in my view, is completely off the mark, and here is why:
The main challenge of embedded is that you are in charge of controlling and managing everything. The developer is closer to the hardware and the cost of things breaking is far higher because you cannot for one second forget about some part of the technology stack that's below you. Everything is suspect, and nothing can be ignored.
On the web, you get used to your automatic garbage collection, your GUI toolkits, your nice browser sandbox with infinite memory that gets automagically replenished, your in-browser JavaScript debugger and all that jazz. You get to enjoy none of it in the embedded systems I've worked with.
Fixing embedded systems in the field is freaking hard, so the quality of code matters is in a completely different dimension from what's on the web today. Now, I am not talking about Linksys router or your iPhone. That's just a fraction of "embedded" devices. I am talking about things that don't have a TCP/IP stack (or any connection to the outside world), don't have a GUI, and are installed at the contractor rate of $1,000/hr and must exist in the field for 10-20 years. There are millions of these devices shipping every month, and they are all around us.
Are you telling me these systems are easier to design than a webpage that can be twiddled with at your whim a million times a day?
Don't downvote just yet! Just so you know where I am coming from:
I am a product manager for a 100K LOC embedded stack that runs in 128K of flash and 8K of RAM. It's all C code, no OS, no toolkits, no MMUs, no garbage collection and no dynamic memory allocation. These devices get 15 years on a single battery and go inside your house. I've also had good exposure (not an expert) to the online technologies the author mentions. Yes, things may be tough to learn (I don't actually believe they are), but the web is a lot more forgiving of mistakes too.
You have a point. Sure, embedded problems can be very tricky and difficult -- much more so than web stuff. But most embedded folks don't solve problems of THAT complexity in their day jobs, just as most web programmers aren't implementing Machine Learning code during their day jobs. The embedded problems you're discussing are usually tackled by the elite, or by highly specialized Linux kernel types -- and no, I'm not elite. Many employed embedded people, believe it or not, have never worked with DMA.
I work for an embedded company doing web development and tool chain support for the embedded product. So I kind of have my feet in both buckets as it were.
You're right in that the main difference is control. In the embedded world the developer has total control over everything. And the specifications for the product are very well defined.
The problem with the web world is that the specs are terribly defined or ignored and you depend on APIs that constantly change. Not having to worry about memory management is great in the web world. But instead you get to worry about how your page will render in 5 different browsers that each have decided to only partially implement some standard. At least in the embedded world if a piece of HW doesn't conform to spec it's defective and gets replaced. And you know exactly what that spec is.
I don't know which is worse. Being forced to write everything yourself or depending on the sometimes mediocre code of others?
No doubt, your embedded world presents incredibly difficult problems -- arguably much trickier ones than most web jobs out there. Keep in mind, as the OP and author, I'm comparing the "average" embedded job or desktop software job to the "average" web job. Perhaps I should have made this distinction clearer in the blog article. Most employed embedded engineers do not work on problems as tough as the ones which you describe.
But to me, the biggest challenge with web is the unforgiving avalanche of emerging new technologies a practicing professional must keep abreast of, literally during every spare second of their life, if he or she is to remain employed !! This unrelenting blizzard of new algorithms, new languages, new frameworks, new design methodologies is just another typical day in the life of a highly competent and employable web engineer.
The resource-limited embedded problems at your company are "old school". I'm not saying they're easy, but do the tools and technologies needed to solve such problems change much through the years ?
The main challenge of embedded is that you are in charge of controlling and managing everything. The developer is closer to the hardware and the cost of things breaking is far higher because you cannot for one second forget about some part of the technology stack that's below you. Everything is suspect, and nothing can be ignored.
On the web, you get used to your automatic garbage collection, your GUI toolkits, your nice browser sandbox with infinite memory that gets automagically replenished, your in-browser JavaScript debugger and all that jazz. You get to enjoy none of it in the embedded systems I've worked with.
Fixing embedded systems in the field is freaking hard, so the quality of code matters is in a completely different dimension from what's on the web today. Now, I am not talking about Linksys router or your iPhone. That's just a fraction of "embedded" devices. I am talking about things that don't have a TCP/IP stack (or any connection to the outside world), don't have a GUI, and are installed at the contractor rate of $1,000/hr and must exist in the field for 10-20 years. There are millions of these devices shipping every month, and they are all around us.
Are you telling me these systems are easier to design than a webpage that can be twiddled with at your whim a million times a day?
Don't downvote just yet! Just so you know where I am coming from:
I am a product manager for a 100K LOC embedded stack that runs in 128K of flash and 8K of RAM. It's all C code, no OS, no toolkits, no MMUs, no garbage collection and no dynamic memory allocation. These devices get 15 years on a single battery and go inside your house. I've also had good exposure (not an expert) to the online technologies the author mentions. Yes, things may be tough to learn (I don't actually believe they are), but the web is a lot more forgiving of mistakes too.