Optimizing C++ code is enough of a niche requirement nowadays that it is totally reasonable for you have to train junior devs in this area rather than hiring them ready to go.

If you don't want to train them, pay the price for an experienced C++ developer instead.

> junior software engineers would be able to write and optimize C++ without much supervision

"Junior" and "optimize c++" just do not typically go together. Even more so if you're talking about deep optimizations like cache hit misses, and not just algorithm decisions or breaking down problems properly.

As an anecdotal counterpoint, I'd love to see more people hiring for positions like that. Most C++ jobs are between "we know you're clueless, but hopefully you'll learn" (rare) and "you know this stuff, how are you not in a senior/architect position?". Hacking away on moderately complex performance-conscious code without necessarily spending too much time on architect-level concerns sounds lovely.

> Personal experience. I've been trying to hire moderately competent, junior software engineers would be able to write and optimize C++ without much supervision. They're now more rare than the Sasquatch.

Are you certain they're rare? As opposed to not responding to your hiring ads, for whatever reason?

I do think the percentage of programmers who care about CPU cycles has gone down; I would totally agree with that. Decades ago it used to be that you had to care, it wasn't an option. Today, for most work, it's simply no longer a requirement to worry about cycles. BUT, I've hired lots of kids in recent years who knew plenty about compilers and assembly and caching, so I have a general feeling that they're out there. I would speculate that a lot of the kids who can deal with C++ and performance issues are interested in games...

> ...it definitely pays to know what's going on. Otherwise it's not software engineering, it's cargo cult science and rain dancing, prone to fall apart at the first sign of difficulty. It's like having a certified car mechanic who doesn't know how to open the hood.

It does pay to know what's going on, I totally agree. In some sense literally, as the deeper you go, the more "expert" and "high paid" you will expect the technician to be.

Your analogy to car mechanics is apt in the sense that what you're talking about has already happened in both the auto industry and the tech industry due to increasing complexity of the systems over time -- the first line or two of support people don't fix the internals for you and often don't know how (yet they do "fix" most problems). Even the higher paid expert technicians at car dealers can't fix a huge portion of the problems anymore because the problems are software. Same goes for very smart and very capable QA engineers - they know how to test systems, they know how to find which system is broken, they know how to reproduce issues, but the system may still be a black box. And the engineers writing your core app code still can't generally fix issues in their libraries or operating systems. And so on. So, I personally wouldn't go so far as to say it's cargo cult science or lacking software engineering, we just have more layers than we used to. We can and do engineer at one layer on top of other layers that are black boxes, almost nobody can claim otherwise. But, as you pointed out, you do need people staffing those multiple layers.