[general_ai]

> What makes you think

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. Today, "caring about performance" means picking a language that's only 5x slower than C, rather than 100x slower. Hardly anyone even knows why alignment might be desirable, or how long it takes to fetch memory after a cache miss, or how concurrency primitives actually work. For my generation, "caring about performance" means that C compiler generates suboptimal assembly, and you handcode it because you know better and need that extra oomph.

> It depends on what you're doing

It sure does. You don't have to worry about the lower level stuff every day. We deal with extremely high performance code, and even _we_ don't think about it every day. But 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. You can have a few of those to change tires and broken tail lights on the cheap, but you also need the dudes/dudettes who know what to do when "check engine" light comes on.

[tybit]

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.

[matwood]

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

[general_ai]

Ok, "optimize" might be an overstatement in this case. More like "write code that's not totally oblivious to how compiler will compile it, and how CPU will execute it". A reasonable request for a software professional with a degree, one would hope.

[WildUtah]

"Junior" and "optimize c++" just do not typically go together.

They sure did in the early 1990s. That was the only way you could ship a working product.

[keldaris]

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.

[dahart]

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

[general_ai]

> As opposed to not responding to your hiring ads

Could be response rate, sure. Could be our proximity to Google, which manages to hire C++ devs just fine (fully a half of their codebase is C++).

We've managed to hire some folks after all, with some remedial training they're doing fine. I just wish it wasn't so hard to find them, and they wouldn't require months of close supervision after you hire them.

[mahyarm]

How about all the embedded engineers who go on to become RoR engineers because it pays much better?

Google is probably willing to train people too, which might be a difference for you. C++ isn't that fun of a language compared to others too.

[general_ai]

Nah. Google doesn't "train" per se. They expect that you already know your shit pretty well when you get hired, or else they just don't hire you. From there on out you're on your own. No one will "train" you specifically, although opportunities are sometimes available. In particular, no one will specifically train you to write tight code. Your CLs will just get rejected until you learn that on your own. Source: spent 8 years at Google.