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.
Fellow late 20-something mobile turned server turned embedded dev here as well.
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.
> "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."
> ... 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.
IMO the reason to do embedded is it's super cool. You can actually hold something up and say "I made this". I don't really care for web because it's so ephemeral. I want to be like the previous generation that could point up at the sky at Hubble and say "My code is running on that".
Unless you really love doing low-level stuff, I'd still probably recommend you don't though. As a career, it just doesn't give you the same opportunities.
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.
I actually find the opposite to be true. I can spin up containers, write ruby backends and do frontend design like anyone else. Moving up the stack is easy, especially when you know a little something about the performance impact of doing this vs that. I've seen a lot of people try and fail to move down though. It's a very complicated world that requires a lot of time to get comfortable in. Yea, driving peripherals is "just" writing to a particular memory address but where do you start? How do you find all the relevant documentation? What are the unwritten conventions of how that's done? Big endian/little endian? How long can I make this Interrupt Service Routine before things start to break?
Yes, I agree technically it isn't difficult. Depending on your location career mobility maybe less easy if you get pigeon holed as an "embedded engineer".
If you're doing it because you enjoy it, that's great. But ultimately embedded development doesn't have has good prospects career-wise.
I agree with this. Did embedded for years. Actually started out doing device drivers—as far as I know my name is still on a little driver .c file in the Linux kernel, my one meager claim to fame in life LOL. I eventually left the field partially because of the nonexistent career growth curve. Kind of sad that you can make 2-3X what a typical embedded programmer makes by barely holding some front end JS together, but that’s the reality of supply and demand.
Yeah that is not true at all. I've been doing embedded work for about 8 years and regularly get recruiting messages from/interviews with Apple, Amazon, and Google along with a bunch of smaller companies from around the US. I am currently at a startup working on autonomous quad-copters and we basically can't find really talented embedded engineers. Between IoT and autonomous systems the market for embedded developers is great right now.
Depends on location perhaps? But personally I've not seen that. Google etc. will always be looking for all kinds of people. But are they looking for as many embedded devs? Are they senior positions? If you want to progress within those companies will you need to move out of embedded dev? Those are the questions I'd ask I guess.
Unless you love doing X stuff, I'd recommend that you don't do X stuff because people should ideally do what they love and avoid doing what they don't love.
What I mean is there are aspects of embedded work that can be found in other jobs which are potentially more lucrative and may make your life easier later in your career. So, unless there's something in embedded work in particular, that you can't find elsewhere, it might be considering those jobs.
An example might be, if you like bit twiddling, digging into hard often hardware related problem, you might consider something like an SRE role.
I say turned, when more specifically I'm just a jack of all trades at a small software shop that does custom work across all three domains. I do truly love it, and I'm using it to segue into some EE experience as well, but the majority of my work is still in the mobile side, albeit interacting with the firmware dev I do (lots of BLE stuff).
That sounds like a really nice mix of work. Personally that sounds like great fun. It's also giving you a skill set that you could transition into starting your own thing (building your own product prototypes if you get enough EE stuff). Which sounds great!
I was wondering if you could give me some information about being a embedded software engineer and the skill set required for it. It is something that has always appealed to me as a job. I just finished freshman year of an ECE program (mainly the computer engineering aspect). I have been doing side projects in C for a few years and more recently have been doing a lot of rust. I plan on doing a minor in CS.
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.
ECE/CS minor is pretty much perfect for a super low level role. I was straight CS and I kinda wish I had more formal training in some of the electrical stuff. If you like it, try to get comfortable in VHDL or Verilog FPGA stuff. That opens a lot of doors as well. Being able to do everything from board design through drivers will make you popular with smaller companies and startups that need that capability.
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.
This year I took a logic design course that had a few labs in VHDL with FPGAs which was a lot of fun. Thanks for the info, its good to know that I am on the right track.
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?
Keep in mind that "pay" is a very nebulous concept in software. Embedded work clusters around the same cities that high level work does but I've found there to be more variety in some aspects. Defence work in particular will take you outside the bay area so that helps immensely in terms of income vs expenses. Small companies I've found don't pay well though. Everyone is talking about supply and demand but the reality of the situation is there's a second factor at play. Devs cost money and make money for the company. In web land, you Ctrl-C/Ctrl-V every time you want more money. In the embedded world you're usually interfacing with hardware and hardware has a monetary cost to produce. That cost is actually insanely high by tech world standards so that kills the massive margins that would otherwise go towards fighting for talent. There's also typically more risk due to the fact that you can't just edit a production application to fix it. You have to re-run production every time a flaw is found in hardware and sometimes even in software. That also moves money away from talent.
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.
>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.
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.
Some satellites do run higher level code on the payload side. My company also uses it for our open source telemetry package. That code is typically very isolated though. If it crashes entirely, you can't exactly send someone over to hit the reset button or re-upload the image so you need some sort of hardened supervisory code running on radiation tolerant hardware. The big gotcha though is that space-capable hardware is frequently at least a generation behind commodity stuff so you don't really have a lot of overhead to deal with interpreters or VMs. This is less of an issue on cube sats where you don't care (as much) if it doesn't work and the mission is very short and non-critical.
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.
Not sure if that’s your job req or whether you just found it online, but here’s some unsolicited feedback on it: the way the qualifications are written there are probably less than 10 people on earth who meet them all. As someone who has embedded experience and an interest in space tech, if I were in the job market I’d be so intimidated by that description that I’d probably not even bother applying!
Pro tip: find someone willing to mentor you. Look for companies with people who are willing to help you with that, some will, some won't.
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.
> 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.
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.
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.