The Soon-To-Be-Extinct Embedded Software Engineer
designnews.com
designnews.com
This is horseshit.
The bulk of the embedded developers right now are aging boomers who are soon to be exiting the workforce. I barely know anyone else my age who does this stuff.
Yes the ecosystem is changing. There's been a "recent" movement towards ARM-all-the-things, even the little bit-banging chips that everyone is talking about. You can get uCs with clock rates from the single digit MHz all the way to GHz with loads of features. Most people seem to be running an RTOS on top of anything over a few Mhz but there are a few of us who do things the hard way when things get tight.
That's just the uC stuff though. There's so much more going on in the industry. Someone needs to write the windows drivers for your system, same with pretty much everything that's going on in the linux kernel, android, etc. Embedded wraps the entire computing space. Can't really say the same for any other discipline.
On top of all of this, there's a solid demand from the "mission critical" world for good devs. Airliners, satellites, rockets and cars all, by necessity, run extremely thin stacks consisting almost entirely of C (though some of us are starting the push for Rust). You can't just Python your way to glory in a fly-by-wire controller because that's how you get people killed.
Yes, the pay is mostly shit unless you work for a large company. Qualcomm and similar typically offers six figures starting. I work in aerospace but they're starting to get desperate as they no longer get to pay nothing for getting to build cool flying stuff. YMMV here.
It is indeed bullshit.
I'm working on my Master's in CS right now, and my stepdad, a professional web dev who started in the Apple II days, used to ask me "Why do you still want to learn low level code/hardware/ways of doing things? It seems the industry keeps moving towards higher level frameworks/hardware/products."
The answer I've always given him is because someone has to build the world that the easier to understand, higher level pieces live in. There's still a niche for bespoke, highly performant and well architectured low level code, and there's not really a shortage of jobs because it's not what's being taught in undergrad CS programs, at least at my alma mater and others in my area.
Yes, there are jobs, but I doubt you'll find the scope for advancement, and mobility that being a skilled dev (with good bit manipulation/low level skills) would give you.
An SRE role at Google might be a good example of a position that would involve a good deal of low-level debugging, but is still paid well, looks great on a CV and could advance you to other (and equally interesting positions) easily.
If you're doing it because you enjoy it, that's great. But ultimately embedded development doesn't have has good prospects career-wise.
An example might be, if you like bit twiddling, digging into hard often hardware related problem, you might consider something like an SRE role.
> ... someone has to build the world that the easier to understand, higher level pieces live in."
Ah I love reading that! Some people really enjoy watching other people use or get use out of something they built or helped build. Some people just like knowing that the things they built or worked on are useful to folks and make their days / lives a bit easier. Then there are folks like you who are content to know that exactly because nobody knows your work exists or knows that you worked on that work specifically pretty much means you've done a great job. I'm sure that's an entirely different type of good feeling of knowing the things you worked on were useful.
Every job I found was short term or contract. I really enjoyed the work but I did not enjoy the ever-present need to be looking for a job.
Was I just looking in the wrong place or is it mostly short term/ contract work?
A friend mentioned to me that Spire is doing satellite control software in Python. Presumably it's higher quality than your average python project since you can't wipe it and provision a new one on a fresh satellite when something goes wrong.
On the bus side (the part that controls the satellite's support systems, thrusters, etc) having garbage collection kick off while making orbital adjustments is no bueno. Don't really have to say much more than that.
In the low power realm there's a lot of domain knowledge to learn. What sleep modes allow what, when and how to use them, etc. Don't give up though. It's very rewarding.
Do you think that continuing on this path will still leave open the opportunity for doing embedded software development? The idea of doing safety critical engineering in rust really appeals to me but I am also interested in things like computer architecture so I don't want to only do only a CS degree. Thanks for any information.
As far as employment, there's a lot of stuff going on. Traditionally aerospace (where you'll see the super hard-real-time mission critical stuff) is a PITA because they know the work is desirable and can therefore pay peanuts for people to do it. That's changing though so keep your eyes open. Also, don't do anything that could jeopardize your ability to get and retain a security clearance if you're US based. You'll need one for a lot of those kinds of projects (though not all).
Finally, get used to process. If you do critical work, the more critical, the more process you have to follow. Lots of code reviews, heavy handed version control rules, design and deployment paperwork, etc. It's not bad but it seems to be a shock to everyone.
If you have specific questions, feel free to contact me at gmail.com. I have a couple other responses in this thread that might also be useful to you.
I have heard a little bit about the process from a friend of mine who works in aerospace software engineering, and according to him like 90% of his job is design documents and other paperwork.
I am kinda surprised to hear that the pay isn't very good, but its good to hear that its changing. Is this mostly due to the older workforce retiring or are there other factors that are causing it?
Now, the advent of cheap chinese manufacturing and increases in R&D cash help with a lot of that. The consumer electronics world is cutthroat but research work is pretty easy to come by and IMO very rewarding. Space seems like a potentially profitable sector at the moment, though that currently hinges entirely on one guy and his rockets. If it continues to take off, expect a gold rush in a decade or so.
Long story short, you'll still make good money, just not the 200k starting salaries of the bay area for the most part. Do what interests you and makes you happy or you'll burn out.
Just for some context, a decade ago I was saying the same thing. Glad to see _that_ hasn't changed in the meantime. It's also a core part of my motivations for having _left_ embedded in the first place.
It was actually originally designed as a wifi interface. I think it was mostly used in cheap Android tablets. It just so happens that any generic wifi interface IC has pretty much everything required to make a general purpose IoT microcontroller.
That is to say, they've all cost an ARM or other cheap core inside as well as the Wifi physical interface. Usually the CPU just does data formatting, interfacing and other management tasks.
So, there are lots of those around. In fact if you search for USB wifi dongles on ebay you'll find them for 1 or 2USD. They all have some similar controller inside.
The difference with the esp8266 is that they released the documentation, and started marketing the chip as an IoT device. It's neat, because essentially all the of development costs have already been paid off by the Android tablet market.
I've done embedded work. I could do embedded work, I probably wont because the pay is mostly terrible compared with either traditional software engineering or the more data orientated stuff I usually do.
So, if there is a shortage of embedded engineers, it's because nobody really want to pay them properly. As to moving things up the stack... well that's always been a trend. But someone has to write the board support package and do all the hardware interfacing to the often broken and buggy hardware.
It's really easy to have $1M+ (or basically very large) impact on a business by making data more accessible and providing solid analysis.
On the flip side, it's really hard to have a really large impact writing low level embedded code.
The reason for that is because since it is a well defined problem (control this hardware, send data from here to there) there is not a lot of room for creative flexibility. So it's hard to differentiate yourself above others (even though very technical people know that the quality of low level code can vary dramatically, this often isn't reflected in the success of the business).
At the end of the day I always ask myself, is what I am doing driving business value for my clients. If not, I try to reframe what I am working on so that is the case.
I would rephrase that as the quality of low level code is not often recognized as having a huge impact on the success of the business but when low level code goes wrong it can have very costly negative effects which ripple up through the company. The usual manifestation is a buggy product with many layers of hacked together bloat. Low level code often does not get the attention it deserves because the higher ups don't understand it.
Like the person designing the foundation doesn't have a large impact on the stability of a tower?
Embedded development is very time consuming because it's generally so critical to get right and keep bugs to an absolute minimum. Which is also why it's important to keep it as simple as possible. This inherently limits how creative one can get.
Capitalism doesn't pay for productivity; it pays whatever price it can get away with.
For example, I was working with a device that came with a SoC from a large American/global SoC manufacturer. I ended up disassembling some of the firmware blobs and was able to find the devs on LinkedIn who wrote the BSP and the power management firmware. I found large networks of teams of devs in India working on these very esoteric things.
This is true, and it works for small localized code...but when it comes to application work it backfires a good amount of the time. A serious portion of embedded application work is digesting the business knowledge of the client and translating it into working firmware.
If you need to take a stateside engineer and write and review the specifications to the code, then throw it over the wall, THEN review the finished work before delivery....what was the point in the first place?
Low resource systems won't be going away any time soon either. The ignition (or battery controller) in something like a weed whacker is unlikely to be communicating with anything and will likely be running on a 8 bit processor with no room for libraries.
I don't see that the problem is that we will lose the skillset as suggested in the article. The bigger problem is that we have trouble producing embedded programmers in the first place. The universities/colleges are doing a terrible job. Most embedded programmers picked it up on their own by messing around.
Yes, the ecosystem is changing. Instead of a wide range of embedded CPUs, we're shifting to tiny bit-bangers (8051 or Arduino) and most everything else is ARM Linux. CPUs were never the hard part of embedded. The hard parts have always been (1) debugging the hw/sw interface and (2) meeting realtime requirements, if the system has any.
My job is to secure Web Applications, so usually cleaning up PHP code. But literally everything I do is pointless if the lower level firmware is compromised (it probably already has been).
Very high demand for embedded engineers => too expensive, hard and time consuming to train the needed engineers => market responds by creating API’s so less “traditional” skill is required
I've taken one of Jacob Beningo's courses after working for a long time in embedded and I know exactly where he's coming from. Granted the title is a bit clickbait.
The fact that he's "selling something" doesn't mean he's shill. It actually underlines his authority on the matter.
In this short article he only had a short space to address the state of embedded engineering. But of the key trends, IoS is only one of them. The other important one is the abundance of CPU cycles. It's hardly required to be close to the metal these days. In some cases, yes, but things are hardly bound like they were 10-20 years ago.
Also, perihperals are standardizing. This means the skills are more abundant. Plus, education is widespread, so many things that were mysterious aren't anymore. Next, product cycles are shorter, so shortcomings in products can be fixed in the next rev when better HW is available. Also, SW engineering practices are getting inherited from the rest of SW eng industry, so quality and predictability are increasing. Also traditional CS people can be very effective in embedded areas.
However, there will always be about 10% of the market that is difficult enough or requires enough expertise that only highly experienced people can achieve. These embedded engs can't be replaced any time soon.
I'm sure most of the people in these fields have generic degrees in CS/CE/EE.
The difference between the two is not as great as the article is trying to make it. Yes, there are specialized skills, but that is true of any platform. Win32 and iOS are as far apart from each other as iOS and embedded.
I've worked with several developers with 20+ years embedded experience who wrote horrible, unmaintainable code.
However, the article's main tenet I agree with: Higher level abstractions are being pushed for lots of platforms. A great example of this is Google Things [0]. I have my doubts about the quality of product you'll get by asking Android developers to write "firmware" for you hardware product, but it is evidence of the general push. The author seems to accept that these pushes will be immediately successful. I have my doubts.
After a week and a half I have no interviews even though I have a few beefy side projects (embedded Linux system I designed myself), use both C and c++, heavily, contributed a bug fix to the Linux kernel, and even have 3 years experience at a company. To be fair, there are few jobs like this it seems on nyc (managed to find only ~25 on LinkedIn).
You have to have either existing engineering/industrial area (such as Reading in the UK) or a h/w startup & high tech area such as Cambridge (UK).
Ha. I wish.
We're usually working with chips where the software from the chip vendor isn't done, and isn't going to be done before we need to ship a product.
And then there's issues where the vendor calls it 'done', and it isn't done, and we have to fill in the gaps.
Frameworks have existed since forever, the same as in desktop, server and UI software.
There is a) nothing new here and b) an assumption that the frameworks provide something valuable.
Very poor quality article based on false assumptions and lack of experience.