The pool of talented C++ developers is running dry

> I have worked on codebases where full coverage was obtained using service level tests in a proper pipeline.

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.

> In my neck of the C++ woods, neither are a good choice.

Just off the top of my head: "it's not resizeable" (use a std::vector instead) or "it's allocated on the stack instead of the heap" (you can use a std::unique_ptr to put it on the heap). But what are the reasons to not use `std::array` in your neck of the C++ woods?

> I can't judge the quality of somebody's German, even though it sometimes feels like I should be able to.

The cool part about software languages is that they're implementations of data structures and algorithms. Understanding those gets you most of the way to understanding what the code does regardless of whatever native language is spoken.

I started as an embedded software engineer in the early 90's, and at the time there were lots of well paying jobs compared to other software engineering diciplines.

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.

The article very specifically states "very high levels"

That has two effects:

1) Given how ineffective the hiring process is at selecting skill, they would never hire even Bjarne Stroustrup. Average to incompetent people trying to select "very high level" people usually get scammed by the most imaginative resume bandits.

2) Programming languages are not as fixed as spoken languages, and "very high level" people are making more money in other languages, or less tedious languages.

The article also uses language like "programmers" in a generic sense but the site is specifically for the financial services career field as are all the quotes. I've worked in financial services and the highly skilled people who can learn anything would never learn C++ because it doesn't pay nearly as well as, well, anything else in financial services IT departments. Someone made a huge architectural error in designing a system requiring the highest level C++ programmers but never telling HR to pay them enough to find any. If I were still doing financial services work I'd never learn C++, that would be dumb, I'll make a lot more money learning... anything else in that industry, or learning skills that transfer out of the industry.

The article also mentions automotive, another example of a giant slow moving industry that underpays and over-Dilberts its C++ programmers.

What I enjoyed about my time in financial services is they understood their money depends on generous IT spending, they understood the value of documentation and code review, and it was a stable industry. Not perfect in an absolute sense but "more so relative to other industries". I would have to think for awhile if those values fit the C++ community. My immediate guess is "no" but I'm not certain, everyone liked the generous budget but the constant review and oversight was often a little excessive.

Not just the language, entire toolchain and community are like this. Yesterday I upgraded my Go compiler, everything worked straight away, got free performance improvement on my code. I still shudder when I remember upgrading to a new version of GCC, Clang, MSVC. Took weeks to setup everything and fix newly created bugs. Not getting back... ever.