Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

441–450 of 869 posts

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

#441
The article focuses on the financial world. Historically in the UK (and elsewhere) finance roles have had strong interest for applicants, and high salaries were on offer. So the industry could pick the "most talented".

Now the model has broken down which is the motivation for the article. That's because the "talented" C++ developers have been hived off by the big tech firms (which can pay equivalent salaries or more), or the top video game companies (which generally pay low but make up for it in fun).

What remains are the "normal" developers. But their nature of business means you can't achieve a market edge with that level of talent, all else being equal.

This was never the case for COBOL because that was deployed to keep the business running, not for creating unique value and market edge. So "normal" developers work out just fine.

Finance firms hire a lot of talented graduates. They need to work against their natural inclinations, and provide training and mentorship to get those folks up to speed with C++; a long journey. They don't want to do it due to being seen as providing a cross-subsidy to their competitors when the graduates switch companies.

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

#442

I've been C++ the majority of my career, doing simply amazing shit... and a recent recruiter did not recognize anything I was discussing and asked if I even wrote code. I worked on the original PSX OS, I've delivered over 40 commercial products, all written in C++ and that meant nothing.

I get this too. I wrote a number of design/game engines, design applications, and frameworks in C++ and I get recruiters that don’t understand that and start asking me basic C++ questions. One time they were reaching out to me about a design engine I wrote and didn’t even realize.

> One time they were reaching out to me about a design engine I wrote and didn’t even realize.

Reminds me of this story https://brendangregg.com/blog/2021-06-04/an-unbelievable-dem...

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

#443

Earlier quoted context omitted.

> Mid-six digits as an IC is very doable in North America. No, it's not. Some people who read this comment probably do make that, and it's great, but it's not the norm. You have to be exceptional to get there.

I've been there? It's very doable and far easier than understanding C++ in my opinion.

> Mid-six digits

Do you mean $500k? On levels.fyi for San Francisco you're talking about the 95% percentile of people who upload their salaries (which tends to the higher range anyway), and that's mostly stocks. So in the highest paying part of North America, at the highest paying companies where employees put their salaries on levels.fyi, a small minority can reach $500k. North America as a whole? Nope.

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

#444
As the COBOL pool did before it.

C++ was great in its era but has been supplanted by other languages for safety and performance reasons and it's fine that it's on its way out.

The tail will be long (there are billions of lines of C++ code that will need to be replaced or rendered so fundamental that they cannot be mutated without breaking expectations), but there's no shame in a language running its course.

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

#445
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.

It's not maligned. I've worked on some complex backends some time ago and I would never call those glorified CRUD apps. But my current project is basically Node backend with almost zero business logic. You hit GET endpoint, it returns someORMRepository.find('events').where({ category: 'FUN' }). That's it. React side displays a table with some basic sorting and filtering. Editing and creating and entry is just a basic form. I don't see how else could I call it, it's not that much different from CRUD demos you see in blog posts.

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

#446

Earlier quoted context omitted.

Many hardware companies still see software as just another line item on the BOM: Like a screw or a gasket. It's something you build cheaply or buy from a supplier and sprinkle it on the product somewhere on the assembly line. These hardware companies have no concept of typical measures of software quality, building an ecosystem, release management, sometimes even no concept of source control. They tell an overworked…

> typical measures of software quality 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.

Sort of. There are accurate measures with verifiable predictive power. But useful depends on cost/benefit, which in turn depends on ability to implement and market forces.

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.

[1] https://missionreadysoftware.com/articles/

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

#447
post #57

> Hickling pointed to Java, which has long “seemed to be replacing C++ itself,” but hasn't. This is inaccurate. Java completely ate C++'s lunch in the enterprise space back around the turn of the millennium. Java doesn't need to continue to eat into C++'s marketshare in other domains, because it has more than enough mindshare to sustain itself (there are more Java programmers than C++ programmers), and its very exist…

> Java completely ate C++'s lunch in the enterprise space back around the turn of the millennium When was that C++'s lunch? I might be wrong, but for backend dev(majority of enterprise work?) C++ was never a big thing.

Before Java, C++ was basically the only game in town for frontend and backend. There was always Visual Basic on Windows, and C, and a smattering of various pascal flavors.

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

#448

I find it funny that the headline states it as a general trend while it's looking at it only through the prism of "the finance/crypto industry struggles to find C++ developers". Maybe part of the problem is that people don't want to work on your bullshit crypto products, or just on HFT.

Bingo. I've been approached continuously by recruiters looking for finance and/or crypto firms and I won't go anywhere near it. 2x the salary but 10x the stress with type A finance bros yelling at you constantly? Fuck that. Full disclosure: I'm a sucky C++ programmer. If if they're approaching me that means they've chewed up everyone else they can find. So, another red flag.

> If if they're approaching me that means they've chewed up everyone else they can find. So, another red flag.

This reminds me of an old Woody Allen joke: I wouldn't want to join the club that would have standards low enough to accept me as a member.

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

#449
post #9

Because Python pays more. Or Javascript. Or Ruby. More demand, more salary. Apart from finance, pay is lower than web languages. And finance is small. Embedded systems programming, that also uses the language, pays 30% less than web jobs from my last job hunting period. 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 Europ…

> Employees may be leaving the embedded space 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 th…

There was a time in the late 90s/early 2000s where this happened to driver development on the (Classic) Mac. Companies would make some USB device and get a reasonable driver made for Windows (I assume - I wasn't using Windows at the time). Then they would say, "Well, MacOS is 10% the market of Windows, so we'll pay 1/10th for someone to develop a driver for this." But it turned out that USB worked completely differently on the Mac from how it did on Windows, so none of the Windows code was relevant at all for the Mac devs. They would either get what they paid for (which was terrible for users) or they would not get a Mac driver. This is around the time I stopped buying any device that required installing a driver. Many of these devices didn't really need one because they were regular USB-spec devices (keyboards, scanners, etc.) To this day, I will not install a driver for a fucking mouse. Why would that be required?

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

#450
post #175

Earlier quoted context omitted.

This is what I find astounding. 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.

I worked at a place once where one of the EEs who wrote firmware told me that algorithms and data structures were pointless because in the end it's just bits in a linear address space in RAM. 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 sur…

> one of the EEs who wrote firmware told me that algorithms and data structures were pointless because in the end it's just bits in a linear address space in RAM.

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.

Post reply on HN