Employees may be leaving the embedded space (and C++) for web tech because of this. This is the feeling I get from my local job market (western Europe). Maybe as the old timers retire, job offers will align? Who knows.
The problem is I really like writing C++ (and Rust, etc.)! So I'm cultivating other "systems programming" type career paths; DB internals, have always fascinated me, so I'm trying that direction. Working fulltime in Rust now, but it's hard to find work there that isn't crypto-tainted.
Other people have pointed out that lower pay in embedded has to do with the influence of EE salaries. Which are sadly lower than they rightfully should be.
This is the road I have taken since I started to work professionally, but I yet have to find a lucrative job. I know that I am paid more than microcontroller devs, but less than web devs. The market for kernel developers is not that big either.
Embedded has the advantage that you can usually trust your peripherals more (they’re not a user that randomly presses CTRL-R), there is less framework and thirdparty stuff in your way, and the timing constraints are usually better understood. Webdev also suffers from a ton of UX and UI (animations, wizards, complicated workflows, error handling that needs to be error handled that needs to be error handled), which often results in very complex state machines.
In both cases, observability is key, especially for debugging purposes. I use the same patterns in both cases: a lot of state machines and event driven design, because I get “debugging” for free (I just need to log state + events and I can reproduce any scenario).
The big advantage of web, and one that I always have to adjust to when I come back from a period of time in embedded, is that you can YOLO a lot. YOLO to prod, you can always easily revert. YOLO the UI, because you can trust the user to refresh their page or workaround it (your hardware peripheral won’t). YOLO everything because you’ll never really brick stuff. YOLO timing because you usually don’t have hard or even squishy-hard realtime requirements. YOLO behaviour because you can have realtime feedback on how your system is doing, and pushing a new version is only minutes away.
But “web dev” done right, and I really like having something fast, robust, repeatable and observable, is quite the challenge too.
Lots of framework, in fact most of the runtime environment is not under your control at all (cloud services, for example). Complicated deployment and distributed patterns, often requiring many services to collaborate for a single functionality (DB, monitoring, cache, load balancing, backend itself, storage in just the simpler cases!). And none of this is something you can just plug your debugger into and hack away at it. Very similar to embedded in how I approach it.
Deployment is similar too, in that you will often have a builder system that creates artifacts than then get deployed asynchronously, resulting in heterogeneous environments at least for a while, with needs for proper API boundary design.
Seeing the parallels between both worlds allowed me to use CICD, blue/green, feature flags, data pipelines to the cloud, UI patterns from the then nascent javascript framework explosion back in the late aughts, when that stuff was almost unheard of in embedded environments. I scripted my jtag environment using rhino (javascript on the server, back before node came out) to collect and hot reload pieces of code, while being controlled in the browser. I made a firmware app store for midi controllers I was building.
Embedded UIs also highly benefit from knowing patterns from web frontend, because they are highly event based too, and really benefit from attention to detail (say, animations, error handling, quick responsiveness). At any point the user interacts with the device, through a button, a touchscreen, a sensor, UI feedback should be immediate and obvious (even if it’s just a LED turning on). Good web applications are absolutely amazing in how they achieve that (through CSS, through JS, with nice layout / graphical design patterns).
I think it really pays off to do both.
Also worried about my employability. Not much call for C programmers in 2022. You’ll always fear losing your job.
I love low level though, I do embedded projects for fun! I can probably sling back-end Python for 1.5x the salary. I wish embedded payed better, but it doesn’t and therefore I won’t help alleviate this “shortage”.
embedded/EE is worse.
unless you made into the big few(google,amazon,meta,apple,microsoft,...), salary will plummet by half in general, or even more.
I wonder how much is just EEs looking at SWE resumes and going "why would I pay that much for this?! writing code isn't that hard" I definitely get that vibe from some of the local hw-eng companies.
And they may not be wrong, but.. sorry, that's supply and demand. If I have to go write stupid NodeJS stuff to get paid decently, I guess I'll have to go do that.
The industry has basically screwed itself. It's pretty typical for companies to consider embedded/firmware as EE work that is done in the gaps of the hardware schedule. EEs generally make bad programmers which shouldn't be a surprise as their background is usually not in software development; I similarly shouldn't be hired to do EE work. Because of this the code bases tend to be abysmal in quality.
The salary for these positions tends to be tied to EE salaries which for some reason are quite low. So it's hard to attract good talent willing to deal with the extremely poor code quality and all of the other extra challenges this field has on top of normal software challenges.
Since few software developers are attracted to this niche there's not a lot in terms of libraries or frameworks either, at least not in comparison to most other software ecosystems. I've had a start-up idea for a while now to really close that gap and make embedded development far more sane in terms of feature development and such, but I worry nobody would even bother to use it.
I've been in the embedded space for years now and I've been considering bailing because the problems just aren't worth the pay.
I’m needing todo some highly complex embedded development for my startup in a highly regulated safety critical space.
If web development were like embedded development every single company would be building their own web server, browser, and protocol the two communicate over. It would take a phenomenal amount of time and the actual end product, the website, would be rushed out the door at the very tail end of this massive development effort. As the complexity of the website grows, the worse it gets. All of the features being sold to customers take a backseat to the foundational work that costs the company money either through initial development or ongoing maintenance. Plus there's very little in the way of transferable skills since everything tends to be bespoke from the ground up which poses a problem when hiring.
In this analogy that base layer is really just hardware support. This is starting to change with projects like mbed, zephyr, etc. There's still a lot to be desired here and these realistically only work in a subset of the embedded space.
My idea comes in after this. Keeping with the analogy, consider it Ruby on Rails or NodeJS for the embedded world. Certainly not appropriate for all things, but a lot of what I have worked on professionally would benefit from this.
This is, of course, wrong. However, I think I understand where this EE was coming from.
At the end of the day, once all is said and done, there's a minimal set of instructions necessary for a CPU to perform any task. One could add to that two more variables: minimum time and minimum resources (which is generally understood to be memory).
So, at least three optimization vectors: instructions, time and resources.
Today's bloated software, where everything is layers upon layers of object-oriented code, truly is pointless from the perspective of a CPU solving a problem along a stated combination of the three vectors listed above.
The way I think of this is: OO exists to make the programmer's life easier, not because it is necessary.
I believe this statement to be 100% correct. OO isn't a requirement for solving any computational problem at all.
Of course, this cannot be extended to algorithms. That part of the EE's is likely indefensible.
How about data structures?
Some, I'd say. Again, if the data structure exists only to make it easier for the programmer, one could argue it being unnecessary or, at the very least, perhaps not optimal from the perspective of the three optimization vectors.
He might be onto something you know...
People naturally see their own hard work and skills as primary. I know enough about HW Eng and EE to know that it's actually really hard. That said, it doesn't have the same kind of emergent complexity problems that software has. Not to say that HW eng doesn't have such problems, but they're a different kind.
If you see the product as "the board", then the stuff that runs on the board, that can end up just seeming ancillary.
Very frustrating, for sure.
Don't get me wrong, the Arduino is one of the best things that ever happened to engineering education. Back in college I had to save money for months to buy an entry-level development kit. But it made the non-technical part of my job exponentially harder.
[sigh]
I'm not sure what to do, but I'm trying to get the hell out.
Google/Apple/Nvidia/Qualcomm/Broadcom and gang are having problems retaining talent right now.
But now I think I'll head back to web development for my next job - I think web is better as an employee or as a contractor. It seems to me there is more freedom in webdev, often its possible to work from home or abroad... Embedded on the other hand is encumbered with equipment, oscilloscopes, devboards, protocol analyizers, you name it and often requires onsite hours.
And then there is the pay and job availability... I recall interviewing for a role that involved designing a full-blown operating system for use in the auto-industry. The role was paying 40-50K euro a year in Germany, which is insanely low. React developers earn substantially more, but are required to know substantially less.
The only reason why (I can imagine) someone would chose embedded is probably because its very rewarding and mentally stimulating. Its awesome creating physical devices. Its awesome interfacing with the real world. Its awesome deep diving into bootloaders, memory allocations and exercising a fundamental understanding of computing.
embedded is hard to get remote positions due to hardware involvements, which sucks. on a positive side, the job could be more secure sometimes, but then the low pay truly ruined everything, overall it remains to be negative.
Some of our Rust programs at work, while simple, are hundreds of bytes.
Net result a lot of critical infrastructure and devices suck as much as possible while still getting the job done.
I have found that most of the high end brands have a completely horrible user experience. Miele is the worst I’ve tried, and I found that as you go up the price range even inside that brand the experience gets worse.
The top end Miele induction cooktop takes over 5 seconds to boot up before you can even turn a hob on. The interface has a second of latency on presses. It took me probably 20 seconds to work out how to turn a hob on. I happened to be with my mother at the time and I asked her to try to work out how to turn a hob on and she had failed after 1 minute of trying and gave up and asked me.
It looks nice though.
The thing I find the most infuriating about it is that my attitude towards this stuff is just not understood by designers at all. They complain at my choices because the Miele appliances which they specified are “better quality”. And yet I feel like they can’t have actually tried to use them because as far as I can tell the quality is total garbage.
We opted for a gas hob when we installed our kitchen. Mostly because I like the controllability when cooking. Obviously it's a nightmare for health and the environment but man it makes cooking easier.
Induction stoves powered by natural gas power plants are more efficient than directly cooking with natural gas plus you can use clean solar/wind/nuclear/hydropower or oddballs like geothermal.
For most things which would need cooked on a hob for a long time we use an Instapot electric pressure cooker anyway (out of preference rather than efficiency concern).
At an optimistic 40% efficiency for a stovetop vs 90% for an induction cooktop the breakeven is 25c/kWh which is well above average US electricity prices. Worse that 40% assumes properly sized cookware in contact with the burner, no pilot light, and ignores the cost of venting air outside.
As to total costs, at full blast a propane burner only costs around 1$/hour but some people do a lot of cooking.
I did a survey of all the cooktops/hobs I could find in my city, looking for something that would suit my elderly mum, and I didn’t find a single unit that was usable. Fortunately a salesperson knew of a recently developed “cheap” model from a noname brand, which had individual knobs, so I ordered that, it arrived an month ago so I got it installed, and it has worked very well for my mum.
Usability is not something that most people know to look for when making purchases, so most whiteware ends up with a hideous UI. People will buy shit, then complain, but it doesn’t change their future purchasing habits (e.g. looking for features, especially useless features!)
I bought a middling brand microwave with knobs that has reasonable usability, despite providing all features. The iPhone is another possible counterexample, although I fucking hate many of their usability decisions (remove all multi-tasking shit from my iPad - I only ever initiate it by mistake and I always struggle to revert my mistake - fucking floating windows and split windows and fucking ... at top of the screen).
Probably the cooktop boots up anew each time because otherwise you would have to be able to reset it when it crashes.
For a simple thought experiment, imagine if you could get a good developer for $20 an hour. Every single company on the planet, from a mom and pop shop to big corporations could turn a profit off their work.
Now imagine you could get an electrical engineer for the same price. What percent of businesses could profit from electrical engineering? 2%?
The ideas being demand is low as the senior EEs stay put.
Mom and pop shops could use Excel and did successfully for years. Big banks even ran on gigabyte sized Excel sheets before the 2010s hype bubble (Source: direct experience working in fintech 2010-2015)
Anyone in tech believing the last 10-15 years was about anything but the US government juicing its economy to stay relevant, titillate, and ingratiate itself on now 30-40 something college grads is fooling themselves. All those students are now bought in to keeping the dollar alive.
Software has gotten so over thought and bloated given a “too many cooks in the kitchen.” situation. Templating a git repo with appropriate dep files given mathematical constraints is not rocket science. The past needed to imagine software as out of this world to gain mindshare. Correct and stable electrical state is what really matters.
We are entering a new era of tearing down the cloud monolith for open ML libs that put machines to work, not people.
Behavioral economics has been running the US since before Reagan.
My comment was regarding supply. EE is an art that blossomed in the 80s and 90s in terms of practicing engineers, and has shrunk per capita since. This is largely driven by kids getting drawn into SWE over EE as people look at salaries and modern day billionaires, and figure it to be a no-brainer. Today EEs are a small fraction of the total engineering disciplines, despite being essential for the communication, power generation, distribution, consumer electronics, aerospace, automotive, and of course, the computer hardware industry on which the software one is built; amongst many other growing sectors like robotics, medical, and IoT.
If there are a legion of EEs are set to retire in the next 5-10 years, and all the would-be EEs are now designing web apps, surely at some point the supply/demand scales start to tip one way? Many of the above industries are abstracting everything to software platforms as time goes on, but no amount of money can make a SW dev design a power-train for a car, antenna for a 5G device, or program an FPGA for silicon verification.
To become an EE you need a 4-year degree and a whole heck of a lot of knowledge about things that are a real pain in the ass for laypeople like calculating inductance, capacitance, and impedance (<shudder>).
You don't need much knowledge to make a circuit board, no. But when your boss wants to add a USB 3.0 hub to your product it suddenly becomes a, "wow, we really need an EE" job (because the spec has so many requirements and you're not going to get your product certified unless you can demonstrate that you followed it).
Not quite.
For most modern high speed designs PCB's are very far from being simple. Signal and power integrity are critical. It doesn't help that these can be "voodoo" fields where, a bit like RF, years of experience as well as the theoretical foundation are really important.
That said, I think I know where you are coming from. A ton of low-performance embedded designs these days can be done by people with very little EE education. Anyone can learn anything online. There are plenty of resources. This is a good thing, of course.
I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science.
Sorry to burst your bubble...
Glad you learned enough to do it and had fun with it.
Yet, such PCB's are trivial to design. Heck, one could auto-route something like that and get a working board for prototyping. In fact, I have done exactly that many times over the last four decades for keyboard/control-panel boards. And auto-routers suck. The fact that one can actually use one for a PCB is a good indicator of how trivial that design might be.
One of the big differences between hobby PCB's and professional EE-driven PCB's is in manufacturing and reliability.
It's one thing to make one or a few of something, anything. Quite another to make hundreds, thousands, tens of thousands, millions. As an example, I am pretty sure you did not run your design through safety, environmental, vibration, susceptibility and emissions testing.
For an example of complex design one can look at such things as almost any dynamic RAM implementation, from SDR to DDRn. Timing, signal integrity and power integrity are a big deal and can make a massive difference in performance and reliability.
Another example is just-about any PCB used in automotive designs. They have to survive brutal power, thermal, vibration and RF environments for decades. This is not trivial.
Other fields with critical needs are medical, aerospace (which includes civilian flight) and industrial.
Consumer electronics is actually quite critical at the limit because you are dealing with very large numbers of units being manufactured. In other words, while a design for something like an industrial CNC machine might only require a few hundred or a few thousands of boards per year, in consumer electronics one can easily be in a situation where we are running 50K to 200K boards per month. Bad designs can literally sink a company.
I understand though. From the frame of reference of a hobbyist or enthusiast everything can look simple. That's pretty much because they just don't have enough knowledge or information. This means they only have access to the most superficial of constraints, which makes PCB's seem easy, maybe even trivial.
As my wife likes to say: A google search is not a substitute for my medical degree.
No, analog keyboard PCBs are not trivial at all. You have to keep a lot of things in mind when routing your analog VS digital tracks. Especially if you've got per-key RGB LEDs right next to your hall effect sensors (can be a lot of noise if you don't do it right).
Not only that but you also have to figure out how to get loads of analog sensors into a microcontroller that may only have 4 analog pins (e.g. RP2040). In a way that can be scanned fast enough for 1ms response times (again, without generating a ton of noise).
It's not so simple like an electromechanical keyboard PCB which is quite trivial.
> For an example of complex design one can look at such things as almost any dynamic RAM implementation, from SDR to DDRn. Timing, signal integrity and power integrity are a big deal and can make a massive difference in performance and reliability.
...except 99% of all PCBs aren't that complicated. You don't need to know the specifics of RF in order to design a board that controls some LEDs.
> ...except 99% of all PCBs aren't that complicated. You don't need to know the specifics of RF in order to design a board that controls some LEDs.
There is a difference between creating something that works, which is easy enough to do, and creating something that is competitive on the consumer market, i.e. that BARELY works. This is the difference and why you would pay an EE to do this job.
https://github.com/riskable/void_switch
...and so I can do this:
https://gfycat.com/costlyglaringhyracotherium
..and this:
https://gfycat.com/unconsciousvigilantkinglet
You can clean it in the sink with soap and water because there's no electrical contacts or components in the switches.
... But that's really just scratching the surface of what it can do.
Sorry. This isn't meant as an insult at all. Yes, this stuff is trivial. I know it might not seem that way to you because you are not an EE. I get it. That does not make it complex. For you, maybe. Not for me or any capable EE.
Yes, having designed plenty of challenging analog products I can definitely say that analog has its own set of challenges. Designing keyboards with hall effect switches isn't in that category.
In fact, I could easily make the argument that high speed digital is actually analog design.
> You don't need to know the specifics of RF in order to design a board that controls some LEDs.
I would like to see your boards pass FCC, CE, TUV and UL certification.
Look, there's nothing wrong with being a hobbyist and having a great time designing stuff. Bravo for having learned enough to have done what you shared. That is definitely something to admire. Just understand that your experience does not give you the ability to fully grasp professional EE reality.
I sometimes run little 30 minute programming workshops where I teach people enough of the basics that they can walk away with something they’ve made. Give a novice 3 months to go through an bootcamp and they can become a half useful programmer.
But the “other half” of their knowledge will take a lifetime to learn. In just the last 2 weeks my job has involved: crypto algorithms, security threat modelling, distributed systems design, network protocols, binary serialisation, Async vs sync design choices, algorithmic optimization and CRDTs.
It’s easy enough to be a “good enough” programmer with a few months of study. But it takes a lifetime of work if you want to be an all terrain developer.
Yes, definitely. And, BTW, this also means that lots of useful work can be done without necessarily having golden credentials.
Here's where I see a huge difference between hardware and software at scale (I have been doing so for 40 years): Hardware, again, at scale, represents a serious financial and technical commitment at the point of release. Software gives you the ability to release a minimum-viable-product that mostly works and issues fixes or updates as often as needed.
If we imagine a world where v1.0 of a piece of software must work 100% correct and have a useful service life of, say, ten or twenty years, we come close to the kind of commitment real electronics design requires. You have to get it right or the company is out of business. Not so with most software products, be it embedded, desktop, industrial or web.
If I go back to the late 80's, I remember releasing a small electronic product that gave us tons of problems. The design went through extensive testing --or so I thought-- and yet, contact with actual users managed to reveal problems. I had to accelerate the next-generation design, put it through more extensive testing and release it. We had to replace hundreds of the first generation units for free because we felt it did not represent what we wanted to deliver. This is where knowledge and experience can be invaluable.
A "modern" web dev needs to know a whole bunch of crap nowadays. Not saying it's insanely hard but its not that easy. But sure, getting a job as a junior should be way easier than EE.
Wages are not bad for the area i'm in, which is fairly rural, but could be a lot better for the work involved. Move to a big city would probably help but I like the quieter lifestyle.
I've not done any web development full time for close 20 years, first started writing JSP code. Dabbled with a few personal website designs since then. I'm sure if I went back to web development, it may pay more but I don't think it would have the same level of job satisfaction for me. I try to keep up to date on some of the technologies used but it seems overwhelming from the outside.
Part is resistence to change, but I do find the work for the most part enjoyable so it's a risk to change jobs as well.
The reality is that EE jobs are a small fraction of the software ones and supply is keeping up with demand, so there's no upward salary pressure.
After the work was done, they shed nearly all the contractors and about half of their previous full time employees. Just quadrupled their staff to make a voting machine then fired them all.
They hired me as an "Embedded Software" on their Firmware team. It was a total shitshow we didn't have unit tests or CI. The new hires insisted on it and I spent a bunch of time maintaining a Jenkins setup for the team that really helped.
The pay wasn't great, a little less than defense contracting, which was a little less than insurance companies and slow finance companies.
If that is what most embedded development is like then I see why it is brings the average down.
Let's imagine that the split for all software shops is 80/20, with 80% being crappy, and 20% being decent. If there are 10 embedded software shops out there, it means there are only 2 decent embedded shops out there that an engineer can work at. Meanwhile, if there are 1000 non-embedded software shops, it means that there are 200 decent shops an engineer can work at.
This creates a wild disparity, even if the ratio of crappy to decent is exactly the same for all software shops in general.
The 20% decent shops are retaining their engineers and only growing at a sustainable rate. Available new jobs are filled with a referral since every employee is constantly bragging to their friends. So they post few / no new jobs online.
The 80% crappy shops are shedding employees (turnover) and also poorly managed so they fire everyone and rehire later. Only the worst employees decide to remain during such a purge. So most new posted jobs (more than 80%) are for such companies.
Then the 80% crappy companies talk about their issues finding staff and you get articles complaining how hard it is to find XYZ employees (interns, C++, even supermarket staff). But the real problem is the company in question, not the industry as a whole.
There was no automated test whatsoever. QA department was just manually clicking things on a client that would connect to my c++ thing.
When I wrote a couple of unit tests I got told off because I was wasting time not doing features.
The last time I actually had to argue for unit tests was in defense contracting and not for the team I was working on. Some idiot at a lunch-and-learn community thing tried to claim there was no short term gain from them and we had defined short term in months. He could not believe that unit tests can help the developer writing them and the help the team the very next sprint.
I hope he learned better or got forced out of tech.
I have also worked on codebases where there were only tests at the level of collections of services. Those took too long to run to be useful. I want to push and see if I broke anything, not wait hours and hours. If a full system level test could complete in a few minutes I think I would be fine with that too. The key is checking your coverage to know you are testing stuff, and to write tests that matter. Coverage can be an antimetric.
Sounds ideal to me. Add testing where it is cheap enough to justify, and maybe just a little more than you think you really need because they pay off so often.
If your mocks and fixtures get too big you might not be testing the code in question meaningfully.
Coverage and test quality/quantity need to scale with the associated risk. Perhaps "Flight planner for Air Force Weather" gets more testing than "Video game User Interface" and that's ok. Even in gaming, the engine team should have more tests than the game teams.
At one point I was tasked with shuffling the data layout on disk in real time to mitigate de-anonymization attacks. Security was real concern.
Crypto everywhere. The voted ballots were encrypted with keys generated and delivered immediately before the election. No networking by default. The end product had all the right things.
That said, no one had clearances, third party auditors were morons, and pay wasn't great. So if I were an attacker I would just try to bribe people to make the changes I want. Can't bribe a ballot box company to election tamper, because they just make boxes.
With all that effort they are still needless voting machines, they each count a few thousand votes and not all produce a physical paper trail. Because they have software and logic in them they need a constant chain of custody to make sure that the code we wrote is what is actually run.
Just use a box and paper, it is safer all the ways digital things suck. A precinct counting votes only needs to tally a few thousand ballots so it might take a team of people a hour or two, less time than to fix a potential technical problem.
And paper can more easily have bipartisan oversight and can have physical security measures that are impractical on a computer.
All that said I have no reason to believe our elections have been tampered with on a national level or that anyone other than a local republican may have used our machines to steal elections, even then no firm or even circumstantial evidence, just baseless suspicions and conspiracy theory level anomalies.
Reason is simple: electronic voting machines with no logging, paper trail or anything. And the common people doesn't have permission to do penetration tests or read the entire source. All of it is proprietary and secretive with no public testing basically.
For years the now president, when he was still congressman, been trying to make a law where the voting machines will print the vote, and deposit on a box. This way people can count the votes printed not just trust the machine, but the government keep inventing reasons to not allow this, even when a law passed, judiciary struck it down.
Thus today people are protesting, seemly almost half of the country voted for him, the difference was tiny, they are protesting. The winner insists elections were fair, but how you prove it when the machines are proprietary and secret? How you prove it when they have no log of votes, and instead just print the totals? In a country full of corruption, and where the the mafia literally made a party to commemorate a specific person became chief election judge, how you trust nobody bribed the manufacturer or the programmers?
I think mandating that voting machines be open source is a good idea to me. Here in the US we have 3rd party auditing companies. Various US State and the Federal Government all have different testing/auditing labs that they have certified they trust. Then each voting machine company has to convince them that it is good to sell to the governments that trust them. The final build that the lab signs off on gets a cryptographic signature and the poll workers are supposed to check that it matches what they are given to run on their machines just before the setup their machines for voting.
Do Brazil have anything similar with auditors or inspectors? Or at least some crypto connecting the vendor to the polling locations?
Every year before elections, the government entity responsible for the voting machines invites hackers to run penetration tests [0].
> Or at least some crypto connecting the vendor to the polling locations?
The machines have no internet access at all.
[0, Portuguese]: https://www.tse.jus.br/comunicacao/noticias/2020/Abril/voce-...
I highly recommend the experience if you’re Australian - it was very cool seeing democracy in action. I personally have a lot more faith in our system of voting after seeing it in action first hand.
That said, the senate votes are all typed into a computer by the election officials. It’s just too hard to do preferential voting by hand with ~200 candidates on the ballot.
> Just quadrupled their staff to make a voting machine then fired them all.
Fascinating.
All of this to say: difficulty and importance of a job seems to have almost nothing to do with either the pay one gets, or the respect one gets.
That saying that the client is always right exists for a reason.
in europe c++ pay is in general ridiculously bad, I got some job ads this morning. Senior job in real-time trading in C++ in Paris, multithreading and linux knowledge, english first: 55-75k. Embedded senior C++ FPGA engineer in paris: 45k-65k. No bonus in either position. thanks but no thanks
My advice, get a job around (but not in) London area, if not, get a remote role with a company in south, that gave me a bump from 35k to 71k.
Even better, leave perm and get a contract (outside IR35), you can easily get between 350 to 450 a day.
... and yes, that's doing C++, some Qt, some MFC, some Python, and no PhD/MSc nonsense.
If the government did its job and we had sound money, and taxation were explicit instead of this wacky adjustable-and-unpredictable-devaluation that is inflation, there would be no need for cryptocurrency.
Fwiw I have a grand total of 300€ "invested" (or "lost" if you're a pessimist) in crypto, so I'm not exactly a crypto fanatic.
That's because the point of an economic system is to trick other people into making food for you, and holding money instead of trading it obviously isn't going to lead to that.
Why? Why prioritize spending now rather than later? If I can't defer consumption, I will always need to work, and I can't retire. That would be financial oppression.
> You can't have an asset that's both good to hold over the short and long term.
I am abnormally curious why this is the case.
> That's because the point of an economic system is to trick other people into making food for you
I'd rather they make food for me when I'm old, instead of when I'm young and I can make it for myself. How is this an argument against saving?
> holding money instead of trading it obviously isn't going to lead to that.
While it's true that if everyone saved in the short term, we'd see persistent recessions, it's bound to end, as people start to want to spend their earned money.
In "Die with Zero", an argument is made to allocate and spend everything you've made, because this life is all you've got to do so. I agree with this book.
Even in extreme deflation, people buy things they need. For example, technology prices have been in exponential free fall for decades, yet today the world's largest companies have a lot to do with selling computers, phones, and/or software.
The only reason for government currency inflation is balancing the (wasteful) budget, after the government spends beyond its means. This allows soft-defaults (government paying bond coupons in a diminishing currency) instead of hard-defaults (government failing to pay bond coupons). But both kinds of defaults should be seen as bad, by investors.
To get an idea of the scale of the misallocation, compare the tax revenue to GDP with government spending to GDP. The US government pays for 44% of the yearly domestic product, while only taxing 9.9%. This amounts to a LARGE benefit to those printing money and spending it before price inflation hits.
- https://data.worldbank.org/indicator/GC.TAX.TOTL.GD.ZS
- https://tradingeconomics.com/country-list/government-spendin...
I should've said spent or invested. You can save by turning money into I bonds or stocks for retirement, and that works because it funds something productive (stocks/corp bonds) or the government would like you to defer consumption due to inflation (I bonds).
But remember money (vaguely) represents stored up labor. In nature you can't retire because you can't save up labor; saving money isn't just like a squirrel storing nuts for later, it's also like if the squirrel could put off gathering them at all.
> I am abnormally curious why this is the case.
https://en.wikipedia.org/wiki/Risk–return_spectrum
Long term investments (stocks) are better for retirement because they're riskier.
> I'd rather they make food for me when I'm old, instead of when I'm young and I can make it for myself. How is this an argument against saving?
By "other people" I meant farmers, so you're probably not doing that work yourself. There will probably be farms because other people are continually buying enough from them to keep them producing, but if nobody buys something for long enough it won't get cheaper, the market will cease to exist because nobody will produce it anymore. Saving money/retiring in this way is kind of parasitic.
An example would be FOGBANK, which the government didn't produce for so long it forgot how to do it: https://en.wikipedia.org/wiki/Fogbank
> Even in extreme deflation, people buy things they need.
There was a Great Depression where people stopped being able to do that, you know. Deflation really upsets people. Deflation in Germany also got the Nazis elected.
It's not good to think about "the government spending beyond its means" as if it was a household. The government's the one that invented the money in the first place. A fixed money supply doesn't make sense on a planet with an increasing population that all want to use your money because of how awesome the US financial empire is.
And not only did the US fail to get inflation despite best efforts from ~1980-2020, other countries are seeing inflation now without extra deficits.
> In nature you can't retire because you can't save up labor
That is true. What I can do, I guess, is ensure that I will have what I want in the future. If I don't know what I want, then I want to buy a small piece of everything (index funds).
> are better for retirement because they're riskier.
From the very article you linked: "Having no earnings and paying no coupons, rents or dividends, but instead representing stake in an entirely new monetary system of questionable potential, cryptocurrencies are undoubtedly the highest risk investment known to man."
Of course, here it seems Wikipedia is a bit opinionated, and gambling would be an even higher risk investment. But at that point I'm sure the risk-return relationship would break down.
The Kelly criterion is the optimal to size up how much risk to take over time. If there's even the slightest chance that losing a bet/investment will leave you with zero wealth, then you may not place all your wealth on that bet.
> Saving money/retiring in this way is kind of parasitic.
As some people save, others spend. As I mentioned with "Die with Zero", I will spend all my money eventually. If people do not synchronize their spending with the rest of the economy, the effects will average out, and one individual does not matter. Unfortunately, people tend to buy high and sell low, going on trends. And I've noticed both national and cryptocurrencies go through this - albeit with the interest rate mechanism, national currencies don't drop 80-90% from time to time.
> A fixed money supply doesn't make sense on a planet with an increasing population that all want to use your money because of how awesome the US financial empire is.
The world population is growing at around 1% per year, yet the money supply in the majority of countries grew by 13% (median): https://data.worldbank.org/indicator/FM.LBL.BMNY.ZG?most_rec...
The US, China and India are all above 10%.
> There was a Great Depression where people stopped being able to do that, you know.
You are right. I was exaggerating, because a bit of deflation doesn't hurt. Sever deflation does - as we're seeing right now in China also.
> It's not good to think about "the government spending beyond its means" as if it was a household.
And why not? Incurring debt will only impoverish future members of the "family". As interest rates rose, interest payments are about to exceed the military budget: https://edition.cnn.com/2022/11/01/economy/inflation-fed-deb...
As the population growth slows, or capital reaches diminishing returns as some other finite resource is depleted, it is only responsible to think of the economy as a household, and the money as a reflection of real, existing goods and services, rather than future ones, because future ones might not exist, and debt will become less "productive".
I distinguish between "productivity" of a debt and its yield. Taking on debt means signing up to pay future interest. But the resources you receive in exchange might make it worth paying interest, or might not. This is what I call "productivity" for lack of a better vocabulary. And interest rates or yields are orthogonal to this.
> The government's the one that invented the money in the first place.
The government merely partly captured the monetary velocity multiplier effect caused by fractional reserve.
Fractional reserve was invented by private banks, which create most of the money supply. In spite of their enormous power, and the enormous profits in fees and interest as a result of money creation, banks still go bankrupt by abusing their power, requiring bail-outs (with public money) or bail-ins (with depositors' money).
One such bail-out was immortalized in Bitcoin's first block ("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks").
Khan Academy has a great course on fractional reserve: https://www.khanacademy.org/economics-finance-domain/macroec...
> And not only did the US fail to get inflation despite best efforts from ~1980-2020
In 1980-2020, the CPI went from 82.4 to 258.8, or a ~3.14-fold increase, or a 3.14^(1/40) ~= 2.9% compounded average growth rate. That is not failure to get inflation, it is overinflating by 45% compared to the 2% objective.
What we are seeing now (>10% inflation) is the result of irresponsible pandemic government budgets being mopped-up by the central banks.
By the way, PPP cost $170,000 to $257,000 per retained job-year. I bet employees on payroll during the pandemic were not paid that much.
Confusing or conflating good currencies with investment assets is a common crypto evangelist move.
Profit margins of an EE will almost always be lower than profit margins of a software engineer. A team of software engineers can quickly scale to selling to millions of users (and collect nearly 100% of the resulting revenue as pure profit), whereas a team of EE's cannot a) scale their customer base as quickly, since scaling up manufacturing takes time and b) realize a profit anywhere close to 100% of revenue, since much of their revenue goes towards manufacturing and distribution costs.
In other words, the marginal cost of selling one unit of a physical product is always nonzero, whereas the marginal cost of selling one unit of software is often (very close to) zero. That differential goes towards higher salaries for the software engineer.
There are shorter term effect where for at least a generation there's been too many new grads able to design hardware I2C devices, resulting in too many new grads also able to write I2C driver software as a backup career, resulting in low pay across the board for both fields.
Just because a student likes the field, and can pass the ever more difficult filter classes along the way, doesn't mean there's a job waiting after graduation in that field. For some reason students keep signing up for an EE education even though the odds of them getting an EE job after graduation are very low. The odds of them getting any job, even a high paying one, are good because the majority of the graduating class goes into software development, mostly embedded, but most kids who can, like, bias a class-C amplifier transistor, will never have a job doing EE stuff, there's just too many EE grads for too few EE jobs.
As another example of that effect, see also K-12 education where for at least one generation, the bottom half of the graduating class was never employed in the field, at least in my state. Enrollment for K12 has absolutely cratered in recent years, and now most grads have a reasonable chance of getting a job in their field.
The embedded AI space is a pretty good place to make money writing C++. I was in autonomous vehicles for a bit. It didn't really interrupt my post-Google compensation trajectory, and I got to write performance- and safety-critical C++
There's a whole bunch of ex-C++ devs who have shifted to Rust in this thread.
The existing C++ jobs probably need to shift to Rust.
- My working hours are way more flexible. I pretty much only have to attend meetings which are rare, so I can basically work whenever I want during the day. That means that I can go to the dentist and stuff like that without taking the day off. She has pretty strict hours.
- I can work from anywhere, only requirement is decent internet connection. She has to go to the office because that's the only way she can actually test the code she writes for physical devices.
- My salary is basically double of what my friend makes.
She's currently learning JS so she can just move into web space. If someone can choose between easier job with much better salary, benefits and working conditions, they will do that without thinking, unless they reeeeeally like C++.
E.g., there are hundreds of C++ devs at my company that have the same work from home options and flexible hours as their frontend peers. So these jobs exist.
Why is API design/backend engineering the only software discipline that gets maligned like this? These are bread-and-butter operations. I don't mean to attack you, just noting that I never hear anyone talk about mobile development in the same way, for example.
There are generic data entry tools that solve the entire class of problems in that space. In web tooling there are things like Django's Admin app. In "the ancient world" there is Excel for good and bad and ugly. But those aren't "branded" enough. Those aren't "experiences" that some UI designer has sweated and cried over until they were beautiful. Those "don't understand the domain" or "don't support our processes" or "don't know that we are a special snowflake with special snowflake data" hard enough.
So you just rebuild the same types of things over and over again every time the UI designers get bored or the company decides to use a slightly different version of the same data. Sometimes it can feel a bit Sisyphean.
But each instance is a little different. Each customer wants their flavour of the problem solved.
Long story short: don’t get into a line of work if you don’t like churning out multiples of the same thing for years.
- Dentists have dental hygienists that do the day-to-day grunt work so that dentists can focus on the real problems/exceptional cases (cavities, root canals, etc).
- Architects build the plans, but they leave it to construction workers to actually construct the project.
- Chemical engineers generally work with staffs of chemists and other roles that the take the engineered solution and apply it day-to-day.
Right now, software uses the same job titles "for everything". There's (perhaps intentionally) no differentiation between the people expected to solve the hard problems/engineer the tough solutions and the people hired to plug-and-chug their way through their 15th yet-another-CRUD-app that year. There are complaints in the surrounding threads even that some of the "drone work" pays better salaries and has better hours/corporate cultures than the harder stuff. It's an interesting "upside down" situation compared to even just the three fields specifically referenced here.
I went to an engineering school with the expectation that I would be doing software engineering not just in name but in role, but most of the jobs I've ever worked were paying me to do not that. I certainly know friends who are chemical engineers that also perform the role of chemists for their companies, but those are clearly distinct enough job descriptions with a big enough salary distance that those companies know that any hours my friends put in as chemists rather than their hired job is over-paying those hour rates by a considerable enough amount that they have reason to hire cheaper chemists. I have never seen a software job consider that they may be hugely over-paying a software engineer to do "software development grunt work". Without truly separate job titles and salary considerations that is forever going to be opaque to the accountants at companies.
Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we?
Is that even possible? It's difficult to separate grunt work and problem solving, because you often need similar levels of context to solve both. They also tend to intertwine a lot.
I don't think it is a technical problem keeping software from better sorting its various types of jobs by difficulty and types of problem solving. I think it's far more corporate politics and sociopolitics and a general lazy preference for the current status quo (because it works to company's favors in terms of job description opacity and keeping pay scales confused and under-valued and, uh, not having to worry about "quaint" "old timey" things like professional ethics investigations).
All in all, saying that dev work is repetetive is a hard sell, because if it was, you could just automate it. And we clearly haven't automated even the space of medium-complexity web apps yet.
> still need custom integration work
Define "need" here. I already threw some shade at this by accusing many companies of thinking their every need is a special little snowflake that needs lots of custom tweaks and custom specifics. In my practical experience so much more of that is "want" rather than "need". They want to feel special. They want to feel like they have control. They don't want to pay for the cheap out of the box CMS because it might imply to their executives and shareholders that their entire business is cheap and easily automated.
Some of these CRUD apps are truly "John Hammond syndrome" apps: they want the illusion that no expense was spared. (And just like John Hammond sometimes confusing building out the gift shop and adding fancy food to the restaurant in the Visitor Center with spending enough on redundancy among the critical operations work and staff.)
Which is great - for creating custom admin panels easily. You can't use it as "generic app" you just turn on and it works, so someone has to do it.
It's web development in general.
Where do I even begin? The intrinsic difficulty of most backend problems is very low - read some customer data, save it to a database, call an external API, send data back to customer. The only effort you should have to put in is fighting boredom.
The web dev industry managed to overcomplicate this task to the point where even small startups targeting niche markets have architectures inviting race conditions over distributed systems with tens/hundreds/thousands of working parts.
It doesn't have to be like this. The problem is that your average web dev doesn't know how to scale down (optimize for space/memory/disk consumption), so instead they scale up (more computers). Scaling up isn't necessarily a problem if you know what you're doing, but I've seen a bunch of super-principal engineers regurgitating the popular scaling up buzzwords without actually understanding the tradeoffs. They choose a technology because Google is using it.
It's not fun to fix deep systemic problems in distributed systems when the system has already been running for a long time, and there's a large number of devs working on it. You can't just say "ok, everyone stop working, for a while, we'll take a couple of months to rewrite everything, the customer can wait".
What's worse it that this type of issues would've been obvious from the very beginning to anyone mildly curious to imagine what the future of such a system would look like.
Another type of common issue is slow queries, and the common "solution" results in eventual consistency.
I'll stop now.
> I never hear anyone talk about mobile development in the same way
Mobile development is just as bad, maybe worse. One overly complicated framework (Android), and another one that's fenced-off to non-Mac developers.
I am at a bit of a loss here. On the one hand these very companies cry publicly about a lack of skilled workers, on the other hand you have to fight hard to get your market price and they will not budge on downright immoral clauses (such as not getting paid for x amount of overtime per week) or remote work.
Embedded opportunities have been slowly shrinking for years. For whatever combination of reasons, a lot of employers think that embedded work is easy or otherwise doesn’t require a large budget.
It’s increasingly bizarre to get a well-designed IoT device with a very polished mobile app and web UI, then struggle with hardware factory resets and firmware upgrades because the embedded side of the product didn’t get the same level of attention.
It’s like embedded somehow became an afterthought in the industry. Perhaps because it’s the only part of the system that doesn’t have a highly polished UI layered on top of it? Over the past decade I’ve witnessed multiple companies over focus on anything that goes well into slide decks (UX mock-ups, animations, etc.) or generates vanity metrics (number of backend servers, requests per second to the cloud) while ignoring anything that doesn’t have a visual pop to it (embedded firmware)
Also, "This doesn't meet the current requirements, fix it with software!" The best one was when the case wasn't waterproof... How the fuck is software supposed to fix that? They literally expected the software team to work magic. A lot of pushback got that requirement kicked back over to the mechanical engineering team to address, but it took months. Moronic.
In embedded and other non-software engineering but engineering firms, the management is typically engineers that CAN do their subordinates jobs, they just don't want to.
> They can't be in charge because you can't have engineers answering to non-engineers (ie, very few leads let alone managers coming from the software side). Which leads to a culture that's overly hardware centric with insufficient leadership/management understanding of what software actually entails.
In hardware-centric orgs, software developers are a small step above technicians in their pecking order, sometimes below. The pecking order itself is annoying enough, but when you switch from designing your own ASICs to buying COTS dev boards and primarily only adding software to it, you're not really a hardware company anymore. But it'll take another generation for them to realize it, or a severe crunch if someone comes along and realizes that they can pay embedded devs $200k+ and eat the lunch of half these companies.
I don't know if they kept backups. I wouldn't take that bet.
What is not normal is referring to that part number anywhere except on the BoM.
In your second case, if the only person loading it is the customer, a part number may not solve anything other than the business managing inventory. However, if you're already in the habit of assigning part numbers to everything you build (I have come to be a big advocate of this), then it really is just part of the process.
I've seen a mix of both: there is a standard firmware version for the hardware combined with a set of customer customizations. In this situation, not having a unique part number for each combination (of firmware + customer config) resulted in confusion, angry customers and a manufacturing department having no idea exactly what it was that they were supposed to be building.
Yes, there are other ways of solving these problems but assigning unique numbers works well enough.
it makes some sense, but the company mindset about the role of software is very clear
To play devil's advocate - are there any (useful) measures of software quality? Even this place is mostly programmers and we can't even agree whether we should be writing unit tests or not.
There's a company that looked at reducing critical defects from a sort of actuarial perspective. They have a few decades of cross-industry data. I've used their model, and it works. If you don't need a numerical result, you can just read the white paper about what's most important [1].
So to partially answer your question: unit testing reduces defects, but reducing defects might not be worth the costs to you.
And defects might not be the only thing that matters. There are other measures of goodness, like maintainability, which complicates the answer. You'd have to collect your own data for that.
This is becoming increasingly important as you well note, where devices are all connected, and things like setup and updating and connectivity are crucial. Designing not only a robust, but a user-friendly firmware update process is actually a lot more work than just building a bootloader: you need to communicate to the user, in realtime, what is going on. Cancelling an action needs to be immediate and provide feedback on the process of the cancelling. Error handling needs to provide useful information, and probably a special UX.
These do need to be factored into the embedded software right from the start, because they significantly increase the complexity, and it’s extremely easy for management to miss how crucial that part is. I keep a few horrible chinese consumer electronics devices on hand (webcam, mp3 player, mobile phone) to show what I mean. The only difference between an ipod touch and a noname mp3 player with touchscreen is… the software.
Having to press 3 inaccessible buttons, connect a USB volume named “NO NAME”, have it hang for 2 minutes when unmounting, then show a black screen for 3 more minutes, before showing … that it didn’t update, vs a smoothly progressing update progress bar showing the steps, the devices showing up in my online dashboard as soon as it reboots, that’s what my value as an embedded engineer is.
Why? The issue is that you have to actually ... you know ... PLAN when you have an embedded device.
You can churn the app and the web and the backend infinitely so there is no penalty for doing so. If you take that attitude and apply it to embedded you wind up with an expensive pile of scrap.
I think the problem is more that asking someone to accept low pay to work in C++ (one of the hardest languages to be productive in) doesn’t make any sense. If I’m good at software and know C++ I’ll work at a FAANG, AI company, self driving, or HFT/Hedge Fund for 3x-10x what a random C++ embedded role would pay.
I'd love to go back to embedded but I can't cut my salary in half to do it.
The only job I've ever had that used it was a civil engineering company in a small city in the deep south, and it was mostly just C. The pay was good for the area, but nothing spectacular.
I moved to Seattle and the only C++ jobs were at FAANGs, and only a small portion of jobs at those companies. I worked at two FAANGs and only used Java and C#. I learned frontend web stacks largely due to job flexibility and it almost always pays the best vs amount of stress/work needed to put in.
Yeah I could probably write C++ at <insert FAANG> for 2x the salary but I'd also have to work 80h work weeks and deal with FAANG internal politics and sabotage from coworkers, depending on FAANG and which variation of "don't call it stack ranking" they use this year.
On the other hand I can use TypeScript and work from my home office. I've been considering moving back to the south just because much lower living expenses, family, and availability of remote work for web stacks. I can't get that with C++.
I am a embedded C++ engineer and it feels like I’m watching all my friends who work building web apps have fun on the other side.
- More companies/job openings
- Higher salaries
- Flexible working
- More interesting technology/problems
You are correct about number of job openings though..
And it's blasted to hell with bureaucracy, red tape, toxic work environments and a reputation for having to deal with infrastructure best described as "fossilized". Banks have no one to blame but themselves (and maaaaybe a bit the sometimes insane requirements of financial regulation agencies) for being unable to attract programmers.
At least in Germany, the fintechs have never had much trouble attracting developers... so it's not the finance industry itself, here in Germany it is definitely a culture problem in the established banks that historically have treated IT purely as a cost center instead of the integral part of business they are.
It's a real relief to drop that cognitive load.
I've found C++ shops have "lower" standards for C++ developers. I'm putting "lower" in quotes here because I'm talking relative skill within a given language. It just seems way more common in C++ shops to have situations where "20% of the developers do 80% of the work". This isn't to say there's dead weight in Python/Ruby shops, but my experience in the C++ world was there was always a small group of developers doing most of the work and this is considered normal whereas the same situation in a Python/Ruby shop would be a major crisis.
Despite the demand, if you're a low output Python/Ruby dev you'll likely struggle to hold a career together; hiring will be a slog and you'll get squeezed out of orgs with PIPs every 6 months. The same low output C++ developer could probably stay gainfully employed once hired.
Hopefully this fact might encourage others to pursue C/C++ jobs. There is zero expectations towards being a "rockstar" - if you know the fundamentals and can plod through work at whatever pace you're comfortable with there's probably a job out there for you.
C++ fuels the engines behind Python and JavaScript. Databases, compilers, machine learning libraries: all C++ and actively maintained.
It's remote work.
Remote work is basically forcing ALL software shops to pay more money. If you're smart enough to program C++, you can program ANYTHING.
Let's stop calling it a labor shortage and call it what it really is--a salary shortage.
you start running into problems as you scale, but the reality is you will run into scaling problems regardless of what technology you use, and the ability to move quickly and iterate is much more important for new projects than solving scaling problems before they exist
It's also a breeze if you use .NET and it will run circles around the Ruby app.
and running circles won't matter because for most web apps the DB is usually the bottleneck anyway
.NET is just one example. It could be Go or Java.
high load apps I agree with, pick the technology that is appropriate, but again, for new projects I would say any technology that gives you speed of development (like rails) is far far far superior to speed of the technology.
And on top of that, I rarely log in after hours or on a weekend. In finance, my real breaking point came because there was just an absolute refusal to architect to be able to make changes during market hours, which are essentially 9-6 these days- most securities have a big enough of an extended session that you can't push changes until after. Any significant network changes, host swaps, etc... all had to be done on the weekends. In the web world, you had to bake the ability to make changes on the fly from the very get go, there is no off-time when there is no traffic. And in my last team, we actually avoided pushing changes with any significant risk on Fridays, because if something really bad did happen, it was going to be very hard to get ahold of the right people to diagnose and fix it...
Similarly, there were some AI/ML guys that were rumored to be hauling it in, but this was not for their tech skills- though they were doing mostly python, it was for their AI/ML specific knowledge. As was kind of typical at that place, and most places like it, those guys I think all flamed out and were let go by the time I left. While its not easy to "score a deal" and get promised a very high package for a year or two, its actually much harder in those types of roles to actually keep your seat there. But... if you are actually producing models that generate alpha/profit for the firm, then you are golden.
AI/ML was really just a specific manifestation of a larger trend of if you were on the bleeding edge of a capability that the firm wanted- IE had invented it, or were a very early successful adopter, my firm would have been welling to pay well above typical market to get that. Think along the lines of cloud (2016ish), Kubernetes (2017/18ish), "big data" (2016ish) capability, etc... an alternate route would be to have had successfully engineered change in an org to adopt something like real SRE. Even those types of things, I don't believe anyone was over 7 figures, but maybe? Regardless, the typical path there would be to kind of "burn and churn" those types- IE they build it, maybe its even quite successful, and then thats your niche for the rest of your time there (which is not what most leader types want), or you don't succeed and just get pushed out pretty quick- SRE as a concept was something my previous firm tried several stabs at hiring guys from Google for, but they just never made any real inroads on.
1. At top-tier firms like HRT, Citadel Securities, Jump, TGS, RenTech; there are a decent amount of C++ devs making 7-figures. In many cases, it may depend on how profitable their desk is.
2. At most other firms (mine included), only very senior devs are making 7-figures. These are people managing or overseeing many teams.
This BS that HFT C++ devs make craptons of money has been spread by tech bros and college kids, who have never worked in HFT.
But why is that?
In the 2ks/10's, at least in my area, embedded jobs dried up. Mobile development produced a lot of very high performance SoCs that were cheap, and had high quality already developed middleware layers (Android for instance). They sort of conquered a lot of the embedded media processing space I was an expert in.
As a result I jumped ship to mobile, but it was much higher level programming far away from the SoC, and most of the lower level code was being written in China/South Korea.
This basically meant for the engineers that weren't able to shift, they basically weren't scouting around for, or finding other jobs (in general).
So even though there is a small pool of engineers with these skills, a lot of people left the embedded space at a time when some of those jobs are starting to shift back, leaving a shortfall, but also a pay gap.
And of course, Python is much more broadly applicable.
I don't like to develop in C++ because it's a tiresome mess of issues that don't exist in modern languages.
I don't care about the newer variations or whatever, I still can't do basic things or pull in a library to do it 20 years later so no thanks.
That said - it's not going to go away.
While Rust is nice, I just don't see it replacing C/C++ for a long time due to abi incompatibility etc..
C++ does require more experience, and it needs to pay well or companies won't get the talent.
I have several C++ projects that integrate a portion written in Rust, where the Rust project produces a .a file that is ultimately linked with clang into a larger C++ project.
I definitely agree Rust has a long road to adoption in embedded/low level systems, and particularly areas with custom compilers/toolchains that rely heavily on system specific undefined behavior.
But it's a lot closer than I had thought it was a year or so ago.
Rust trades of absolutely everything for performance - and that's just not the trade-off we want to make in most scenarios. Even for most embedded systems - something that's easy to program, easy to read, easy to support, great tooling etc. is worth more than a 'a bit faster performance'.
If we were to have created something ideal for embedded systems, it would not be Rust. I think it'd be a bit more like Go. Or just like a 'Safe C' with a lot better built-in libraries.
I like Rust but I fear it is not 'the one' and the bandwagon has already left the station so we have to go with it.
Long way to go, of course.
In the extremely underpaid start-up world?
C, Java, C++, Kotlin, Swift, etc - IIUC pay MUCH better and are more in demand at companies where you really make good money as an engineer.
There's really on APPL, GOOG, MSFT, AMZN, FB.
Pinterest, AirBNB, Adobe, Intuit, Snap, Roblox, etc are usually a pretty big drop in pay - but usually above all but the highest of high paying startups.
The vast majority of actual cloud jobs - building cloud infrastructure - are low-level - not Python.
Are you talking about startups using AWS? I'm not sure that's a "cloud" job.
As guy who worked with both C++ and backend I would assume you don't have much experience if you say one is harder than the other. Different beasts, different problems to solve, complexity lies in different parts.
C++ is essentially 4 different languages rolled into one (C, C with classes/OOP, templates, template metaprogramming), and while I am sure greenfield entirely modern C++ projects exist and are a bit nicer to deal with, they are unicorns for most devs out there using the language daily.
But these are all implemented in C++ or C? Those aren't low-paying jobs.
Lol what? Yes they are. I literally work with a whole team of them! Teams at Goole, Apple, Mozilla, etc etc as well.
>In my latest talk, I computed that we have 2 developers paid at full time to maintain Python: I am full time, Barry, Brett, Eric, Steve and Guido have 1 day per week if I understood correctly.
Now from what I understand situation is way better, but still - that's what it looked like just three years ago, when Python already had millions of people writing code in it.
Mostly, but Rust is increasingly replacing them.
TypeScript type checker written in Rust Ruff – a fast Python Linter written in Rust Introducing Turbopack: Rust-based successor to Webpack Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust.
In the meantime, JavaScript and Python is a lot easier to work with, with a higher salary.
I don't know - I legitimately think programming languages are simpler than web applications. Mostly stateless, mostly a big pure function. Compared to the anarchy and chaos of web services seems easy.
Oh, you can change the color of the button on my website? 200k/year!
You eke out maximum performance from poorly documented devices and apis using obscure toolchains and custom built linux kernels to run on small chips that are the backbone of our business? 75k/year!