Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

331–340 of 869 posts

Re: The pool of talented C++ developers is running dry

#331
post #127

Earlier quoted context omitted.

Yes, the embedded space pays terrible, and the employers don't seem great on the whole. When I was at Google I got to work on embedded stuff and really liked it; but I was getting a Google salary. When I left Google I pursued IoT and embedded jobs a bit and while I was not expecting Google level compensation at all, I was astounded at what was going on there, pay wise. General software eng back end jobs pay better. T…

I did a few a few months of contracting at a major voting machine company. They make a significant portion of all US voting machines. They had 4 developer teams Firmware (C++ where I was), UI (web tech on a voting machine), poll book (java), and a web/support team. Before I was hired in a massive influx of contractors each team was something like 3~5 people, except UI which was a new team with the contractor hiring s…

> They make a significant portion of all US voting machines.

> Just quadrupled their staff to make a voting machine then fired them all.

Fascinating.

Re: The pool of talented C++ developers is running dry

#332
post #240

Earlier quoted context omitted.

Ah yes I used to work at a california company as c++ developer. 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.

When was that? I am so glad that for the past 5~6 years every contract I have worked has had unit tests and for the past 10~12 every place has at least accepted their value. 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…

I have worked on codebases where full coverage was obtained using service level tests in a proper pipeline. If you couldn't add a service level test that got your pr coverage, then you were referred to yagni and told to stop doing stuff that wasn't part of your task. I was ok with that, it worked well, and the tests were both easier and faster to write. If the services had been too large maybe it would have fallen apart?

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.

Re: The pool of talented C++ developers is running dry

#333

There's lots of C++ programmers out there. But they're bottled up in FAANG, I think. So you have to be able to compete with that. Working at Google is on the whole a lot of C++. Major parts are moving to Go, certainly. But there's absolutely giant code-bases of pretty cleanly written C++ services, and most Googlers are quite proficient in it and there's whole teams at Google that work on improving C++ standards and t…

> But they're bottled up in FAANG, I think.

Quite a few of them are locked up by AAA games studios, at least the ones that I personally know.

Re: The pool of talented C++ developers is running dry

#334

Earlier quoted context omitted.

Yes, the embedded space pays terrible, and the employers don't seem great on the whole. When I was at Google I got to work on embedded stuff and really liked it; but I was getting a Google salary. When I left Google I pursued IoT and embedded jobs a bit and while I was not expecting Google level compensation at all, I was astounded at what was going on there, pay wise. General software eng back end jobs pay better. T…

>EE salaries are sadly lower than they rightfully should be. 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…

I understand this but I think the biggest driver for software salaries is the sheer number of companies that are interested in hiring software engineers. Plenty of hardware companies are very profitable but do not raise their salaries because there is no market pressure to do so as the more limited job market means EEs/embedded engineers do not switch companies nearly as frequently and switching companies is generally the best way to get a substantial salary increase.

Re: The pool of talented C++ developers is running dry

#335
I was contemplating to work with C++, but coincidentally I got into C (microcontrollers) and C#/.NET (desktop apps). And every time when I am forced to work with C++ (.NET CLR DLL libraries) I am reminded about general typing overhead which I do not need to do in C# - i.e. HPP file with declarations and CPP file with definitions; Enums can't be translated to its string representation directly, but you need to have some helping function to do that... gross.

Re: The pool of talented C++ developers is running dry

#337
post #283

The comments here worry me. I've been programming C++ professionally for 15+ years and I think my comp is pretty good. I didn't shop around though (maybe I should just to see what the market is like, but I hate LeetCode or whatever it is kids do nowadays :) ). We've noticed the C++ pool getting dry when hiring though; nowadays everyone that comes to interview uses Python and JavaScript. We're switching part of our st…

What industry are you in? From the comments, what I've gathered is that anything in the embedded space is awfully underpaid unless you work for Google/Apple/Microsoft/etc. And finance can pay well, but web development pays better.

We're doing cross-platform client applications (primarily Windows desktop apps with some macOS and a bit of iOS/Android).

Re: The pool of talented C++ developers is running dry

#338
post #47

Earlier quoted context omitted.

Yep. I build glorified CRUD apps in NodeJS + React, my friend works on some embedded C++ stuff. - 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 de…

> glorified CRUD apps 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.

[deleted]

Re: The pool of talented C++ developers is running dry

#339
post #247

Earlier quoted context omitted.

That's insane to me... getting into systems programming recently I am well aware of how much harder it is than web dev.

I’ve been in both web and embedded for the last 20 years, and to me web dev “done right” is just as much if not more complicated than embedded, and very similar. In both cases, you have a distributed systems (everything action you take, system wise, is asynchronous, and very uncertain). Debugging is a pain in both cases, because you have only limited access to the system under test (especially in the field), and thin…

I realize I mostly focused on the frontend side here, but you can easily see how backend dev is highly complex too (but that often falls under system programming 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.

Re: The pool of talented C++ developers is running dry

#340
post #239

Earlier quoted context omitted.

Alternatively, web is generally more valuable. You don’t buy a new washing machine because the current firmware sucks, but you will shop somewhere else if Newegg’s website is terrible. That relationship is generally true where people rarely test embedded software until after a purchase, but people tend to jump ship more frequently online. Net result a lot of critical infrastructure and devices suck as much as possibl…

I’m building a house at the moment and I have been insisting that I am able to actually test all the built in appliances with power to see if the software is garbage. 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…

Slightly off topic but imagine an induction cooker with the original iPod control wheel as it's power control.

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.

Post reply on HN