Articles like this are nothing more than a desperate attempt at getting younger generations to learn said topic, so companies can pay them crappy salaries.
The only well paid embedded jobs involve producing weapons ('defence') or gambling ('gaming'), and I'd rather sell crack to kindergartners while also prostituting myself than do that. I did get a bunch of those offers and still do get them every now and again, even though I'm happily employed.
Moved to finance, never looked back. People should plain refuse to work in embedded, maybe then thing will get better.
Also, C++ is the differentiator. People hire for other languages (C# and Rust, in my experience) based on your deep C++ knowledge. And this does make sense, this is a great proxy for your development skills and potential.
I interviewed for Amazon for an embedded/mixed role because that was my forte at the time, and the compensation offered was nothing special, worse than even a mediocre finance sector offer, much better than automotive or general embedded (medical, industry / robots). Could never get an Apple interview (they passed on me twice), though, and I never even thought about the rest (that would require relocation to to places I don't care about).
But since I never actually worked for those companies or have any concrete data I could be completely mistaken. I only have friends working in FANGs in non-embedded roles and embedded friends only working for shit-paying companies, plus some of them are not willing to discuss salaries (suckers). Also, I get the feeling that AMD / Intel / Nvidia operate a bit different than the rest.
Do you know the reason for that? EE is significantly harder to learn than CS, so it baffles me why more people are choosing EE.
I wanted to get away from physics so I ignored that, and in hindsight it was 100% the right choice. But the advice was well intentioned and I considered it.
But yeah, fully agree with you and parent comment. And no, it is not worth it
While naturally CSs don't know about Analog or GHz stuff, EEs know very little about best practices on SW development. So it kinda balances out
It may be because EE is older and more entrenched, or because of ties with the industry. Engineering of any kind has centuries of prestige, historic industrial support, historic large buildings and grants, etc. I would bet on the comparative ease of hiring staff for EE, though. It does make some kind of sense for some academy-prone people to go the academia route in EE. Especially if you sprinkle in some industry side-jobs, because the industry side is not that cushy by itself. This likely makes it easier to staff EE faculties. For CS, academia only makes sense if you have direct industry support (like doing machine learning w/ direct support from a FAANG), and you can expect something like that in very few places in Europe (Zurich, London, maybe Amsterdam?). Otherwise, you really have to hate making money and being respected to get into CS academia. There's a distinct lack of staff for CS, and they let anyone be assistants (at least they did half a decade ago). I remember there being some competition for math positions, and a free for all in CS. Some smart CS people do get fooled into joining, and last around a year until they see it's a waste of time. No amount of academic benefits in later life can offset the accumulated difference in pay.
As an actual failed EE student (moved to CS after 1 year of EE an eternity ago), I definitely agree that it's way harder. I even think that it's not just my affinities, but it objectively requires more effort and is more dense with difficult stuff. What's ironic is that the (officialy!) best EE student of that generation is now a Rust dev for some crypto company (last time I saw him on LinkedIn).
SHOW ME THE MONEY. I'll be a C++ programmer.
Labor supply stories never talk about salaries. I can also see lots of references to embedded and close-to-hardware jobs, which means low salaries, unsexy code, and flawed/buggy toolchains compared to mainstream platforms.
It's right there in the article: "demand". Why do business people pretend basic supply and demand first day microeconomics 101 doesn't exist as soon as you say "labor"?
I suppose this is more fuel for Rust adoption. Rustaceans, is the war won?
Btw, it is INSANE that we pay engineering positions (you know, real ones like electrical/hardware/materials) so poorly compared to software devs. Engineering has professional organizations which, like the AMA, should be able to enforce some degree of good pay.
On the other hand companies with steady profits and little growth have no such expectations and try to pay as little as possible for the software engineers they do need.
I had a large group of devs I used to hang out with. It was about 50/50 front-end and C, C++ guys. Over the last decade or so, every single C developer either transitioned to PHP like yourself, or went the full-stack JS route and have never looked back.
And it was all over the issues around dealing with legacy systems and the poor pay. One guy told me flat out he can make close to twice as much being a very in demand JS developer with great benefits and reasonable hours compared to the horror show of working in government (military) or finance.
Think about how web companies can have very low up-front costs, use a cloud provider and some high-level frameworks for python or JS etc, make a stupid social-media connected app, and start making big money (or get investments assuming they will after capturing many users).
Then think about hardware companies - it's a very competitive space, it's mostly a commodity, the high-level software doesn't care so much about the specific chips providing those cores of cpu and gigs of ram, and what's available on the market is really amazingly powerful at a really amazingly reasonable price, due to competition with other providers in the market, and with older hardware!
It does seem kinda perverse, but ... the closer you are working to the hardware, the cheaper the market for your work, but the further up the stack, the more potential for high pay, based on the higher monetary efficiency of those companies, by running very in-efficiently on super-competitive hardware, and differentiating with features and services etc.
It's really not worth it
I used to work for an industrial company in the defense sector. We were working on very complex problems with difficult requirements in term of resilience and performance. It was extremely interesting: complex algorithms, redondant architecture, hard real time development, most of it in C++ or Ada. Deadlines were tight. It was quite stressful and the pay was miserable.
I left the field entirely but most of my former colleagues now work as fullstack developers for companies building SaaS solutions. They all complain about how boring it is but they all have doubled their total comp.
Meanwhile, I heard from my former boss that the company still complain that the part of the org doing software is more expensive on average per employee that the ones doing production (apparently no one has realised we don’t hire blue collar workers in this part of the company) and keeps grumbling about how talent is too hard to retain in my city.
Just how much can a skilled JS dev get paid?
In general, the big cos hire maybe 1 JS dev for every 2 or 3 backend devs. But they're on the same payscale. From what I've heard, it's more challenging to climb the level ladder, but if you come in at a terminal level and aren't particularly interested in that stuff, it's pretty comfortable.
Midwestern state, large health care company - between $150-$200K (this is FTE status with benefits)
You can also be a contractor (hourly, no benefits) and squeeze a bit more out and just jump around from company to company. Senior JS devs are in seriously high demand right now. I get around 5-6 emails a day from recruiters looking for Senior JS devs.
Most of FAANG backend infrastructure is written in C++. Lots of open positions as senior folks retire early from there.
Note the C/C++/C#/SQL cluster at $70k/12years of experience.
> Wt is a web GUI library in modern C++. Quickly develop highly interactive web UIs with widgets, without having to write a single line of JavaScript. Wt handles all request handling and page rendering for you, so you can focus on functionality.
HN submission: https://news.ycombinator.com/item?id=23812791
I actually doing all web backend using C++. I do not render to HTML though. All JSON based RPC. Rendering done by front end JavaScript.
I get paid very well doing embedded firmware dev, but that’s because we don’t make money on our hardware, we make money on the software that it talks to for industrial IoT analytics
Is the entity you are selling your services to earning a large profit margin? If yes, then it is possible (but not guaranteed) for you to earn more. If not, then look elsewhere.
Generally, this situation happens in businesses that can scale with little to no marginal costs (software, media), can use governments to defend its property (intellectual property, land), and can be easily used as collateral (land) with which you can obtain leverage (money).
1. A lot of the tooling is made by the hardware suppliers. Hardware suppliers tend to be very bad at writing desktop software; I have some theories as to why that is, but no direct evidence for them.
2. When tools are selected, they are rarely evaluated by software developers who will be using them. It's more like "Here's a list of boxes anything our development tools need to check" and then the final selection for anything that checks engoubh boxes is done for business reasons (cost, likely availability of support down the line &c.)
3. The same reason that embedded developers are often paid poor salaries; for a lot of hardware companies, the firmware development is treated more as a cost-center than as something that generates revenue.
My personal experience also says that you spend much less time to build something profitable in JS and PHP than in C or C++.
I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up. Hopefully as a result of moving to languages like Rust - it would work out best for all developers. But it's not looking good in the C++ land salary-wise now.
Maybe. I've made the jump from pure embedded (spent over 15 years in embedded) to backend (Go, with some rudimentary Java thrown into the mix). I literally doubled my salary in the space of 12 months.
In 20 years, are they going to hire my retired old ass to make their codebase live another 5 years longer, or will they simply bite the bullet and rewrite?
> Hopefully as a result of moving to languages like Rust - it would work out best for all developers.
It could happen, but I'm not that bullish on that happening:
1. No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety[1] - the end result of using Rust on a 2kb RAM/8MHz chip (atmega328, or xmega, or one of the stm32s, for example) is going to be using unsafe everywhere anyway.
2. High rampup - the majority of knowledge needed for low-level comes from EE, not CS. Already Rust has problems with adoption amongst CS people, who (in theory anyway) have all the requisite knowledge and motivation to climb the learning curve. I'd bet money that EEs won't even bother looking beyond the awful syntax.
3. Better alternatives - all those higher-level embedded projects such as RPi, Beaglebone, etc that run Linux have better alternatives for programming them than Rust. Most custom code written for the RPi is in Python, for example. Someone looking to develop on these boards is almost certainly better off using Go instead of Python, and Python instead of Rust.
So given that there's a) no benefit on low-powered devices, b) there's better alternatives on high-powered devices and c) it's a complicated language with slow ramp-up, I'm having trouble in seeing exactly where it fits in for embedded.
> But it's not looking good in the C++ land salary-wise now.
Nope, it isn't. If enough C++ devs jump ship (and, to be honest, in low-level embedded C++ as you know it isn't used much anyway), then salaries will rise again.
The problem is, as someone else pointed out, that many of the places using C++ are shooting themselves in the foot, because they want senior and experienced people who can ramp up quickly on the latest C++ standard, but without a pipeline of unskilled/juniors, there's only a few number of years before there'd be out of any C++ devs.
And because it's not an attractive language, there's no one switching from (for example) Java to C++, or C# to C++, while there are plenty switching from C++ to Java or C#.
[1] Beyond which, it is not clear if safe Rust will ever be able to interact with various embedded OSes for these chips; most of them are external kernels anyway, so there is no way to use those kernels without using C.
Where they have enough grunt to do a lot of tasks at the same time, all driven by config over the network, with less hard real-time requirements for some tasks and stronger requirements for others.
That’s not that big a segment though, I would think. And in some ways, just chucking extra slower chips at the problem on the same board is simpler.
The Rust embedded ecosystem has lots of benefits in addition to pure memory safety, which is basically table stakes for a modern language. It gives you a vastly improved DevX, at least if you aren't using hardware that's too exotic for which only proprietary C/C++ toolchains are available.
There's less C++ devs, C++ is harder, demand is still high. Why are the salaries low?
If I am a C++ developer, in my late 50s, close to retirement, and know C++ fairly well, don't want to learn a brand new system which I won't be coding in for much longer, and already have my financials all set...
I won't be looking for that early retirement big cash payouts. I just want my flow of cash for a good retirement, to go on my vacations, and to buy gifts for the kids / grandkids.
I'd be willing to settle for a lower pay with low stress and solid job security.
Remember the desires of people later in life and those early in life aren't the same. If you got 10 more years of work left, you don't want to be in a high stakes high intensity work environment. I worked with one such man. He'd fall asleep while coding mid day. Nobody bothered him. He just chipped away at his projects at his own pace and was happy to not be bothered.
Sounds like such a company is looking for a boomer/genx who's still got skills and willing to settle for not being bothered too much.
COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Are there other sources (articles, research, blogposts) that talk about this?
> COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Not anymore.
I am frequenting gamedev forums, and reading gamedev chatter in general (seeing youtube videos on game conferences, presentations on games development, etc).
Maybe 1 in 10 of the people in these gamedev places actually program in C++. Mostly they'll use Unity (C#) or Unreal Engine Blueprints, with some Godot getting popular and a few statistical-noise engines being used (Love2d, etc).
What you are saying used to be true; on gamedev forums almost everyone used to be able to program in C++. Now very few do.
Yes, Unity is the default engine in the indie scene, but what are EA, Ubisoft, Embracer, Take Two, etc. hiring people to work with? Because these are the meat grinders who hire fresh college grads by the hundreds and work them like oxen until they burn out.
I wonder how many programmers are used at the AAA publishers. Maybe someone on HN who works as a gamedev (ISTR one or two people in the past saying that they worked for AAA developers) can answer that one.
(As an aside: I've got my eyes on FNA which just hit some milestones with using .NET 7 AOT for pure C# games on the major consoles. That's pretty exciting.)
Unreal is the truly wild one because to my understanding Unreal Engine Blueprints are a terrible half-baked not-quite-scripting language and most Unreal developers have to do most of their "proper" scripting in C/C++ directly. (With some statistical anomalies allegedly doing things like bolting in Lua interpreters.)
But yeah, outside of indies and small game companies my impression is that C/C++ is still king and there's some consternation that developers learning from the indie side are sometimes, if interviewing for AAA teams, getting shuttled to "tools" positions because that's where AAA's only C# code lives (in non-critical tools outside of the games). (Though that's mostly anecdata from reading similar gamedev forums.)
There are pockets of the C++ ecosystem where this isn't true (e.g. HFT).
But bottom-line, it's a business thing, not a skills thing. There are also a lot more C++ devs than the zeitgeist would suggest. Far too many to cause a "COBOL effect" where supply constraints on talent dictate market price.
Indeed, many businesses correctly decide there's no benefit to using a difficult tool that isn't required, and choose an easier tool that produces a better business outcome.
e.g. suppose you're a non-tech enterprise (bank, utility, etc) and you need to build a bunch of backend web services to support your internal operations. If you decide to implement them in Go, which is arguably a domain specific language for building web services, then you can probably deliver the project by hiring a bunch of fresh grads and putting one intermediate to senior programmer in place to lead the effort, even if no one has any Go experience.
arguably if you try to deliver the same business outcome in a random enterprise context using C++, a project team will likely have a far more difficult time getting basic HTTP / TLS server stuff in place, and if there's lots of rookies on the team, they'll keep making foot-gun memory error mistakes.
Sure, maybe if it was built in C++ by highly senior engineers, and subjected to a thorough QA process, you could end up with a system that's much more efficient at runtime than what could be cobbled together by less experienced engineers with an easier language and a good standard library. But in most business settings efficiency isn't the bottleneck, it's delivery speed and then maintenance costs, which are driven by staffing and how expensive it is to change the code each time the requirements change.
Sure, and a scalpel is a lot sharper and more precise than a lawnmower.
Which one do you think will result in more expensive lawn maintenance?
Not really. I've spent more time debugging JavaScript than debugging C++.
It used to be hard. Modern C++ is actually a quite pleasant language.
The issue is libraries. For example, one very basic functionality of any programming language is DB connection.
In particular, MySQL is very widely used. The C++ libraries (c++ connector) are older, less maintained and just plain broken in the last Ubuntu (it's Oracle's fault, and that can't be helped). They are more stable in Python, for example. The reason is trying to force SSL, reading the source code of the C++ connector it's clear it was intentional.
So, for many things that should have a well maintained library, there's actually not a good C++ one. Web servers are another example. There are only one or two libraries, very opinionated and with "proprietary" widgets, and that's it. Nothing comparable to Laravel or FastAPI.
In other words: the language is fine. C++ is a fine language with a fast runtime, and modern practices and implementations are pleasant to use. It's the disregarded ecosystem in C++ the one that needs improvements. Libraries, package management, build systems, etc. Even then, for performance, some things are only available in C++.