Now, nothing, and you if you want to train a new person, you do it on your own time.
I have seen that too over the years and even been to a couple when I went to other companies, 99% of the time these classes are worthless and consists of marketing drivel. Half the class contains statements like "You can do it the hard way, or the easy way if you purchase ....".
One instructor even stated "You do not need to worry about running out of memory, allocate as much as you want". That class was 20+ years ago. After that I told my manager I will not go to any more vendor classes.
The training I am referring to is by experienced peers and goes on for many months where your work is reviewed in detail, 1 line at a time with you there. That use to happen decades ago, now no more.
The pushback I've received is something I'd categorize as "cart before the horse" - executives want to know exactly what will be achieved with such effort before approving any expenditure.
The teams I've been involved with - training has generally come organically and grass roots.
"I'd rather use a threading library written by one great programmer than by ten average programmers."
I see plenty of php logic which is far more likely to be publicly exposed and generally of a terrible quality.
But I've really got to ask - at that point do you really want to program in C++ anymore or is it just better to use a safer language that removes pointers entirely?
And while there are some kinds of applications where never performing heap allocations is viable, this design is simply not an option for a huge number of applications.
Any C++ program that does not do heap allocations either uses arrays as a substitute for the same thing or isn't a general purpose application.
I use safer languages when appropriate but there are cases where they would introduce more bugs than they address.
Such as? Genuinely curious.
If you implement something like a database kernel almost entirely in user space, which is what you want to do if you care about performance, you have a new set of problems that languages like Rust were not designed to solve. Ownership, mutability, and lifetimes are not resolvable for most objects at compile-time, they can only be resolved dynamically at runtime. With C++, you can make these look like ordinary objects with ordinary behaviors, with metaprogramming abstractions under the hood arbitrating the chaos. Things that look unsafe are actually guaranteed safe by the underlying abstractions. In this type of software, almost your entire address space is “unsafe” in some way, so it is enormously useful to be able to overlay a safety model that does not rely on the compiler, since the compiler cannot solve these cases.
I use both C++ and Rust in production environments. There are cases where C++ used well is legitimately safer, theoretically and empirically, which is why I still use C++ for some things. Rust may become stronger at dealing with these cases but it still has many years to go. (Also, Rust async story is a hot mess, and you really need async for scalable, performant systems software.)
How do you manage heap allocations without ever touching a pointer?
That doesn't seem like a contradiction at all. As you say, they want to hire trained workers rather than providing training themselves. Also, complaining is free while hiring good people is not...
Even in highly regulated, controlled environments memory safety is still an issue. I have seen bugs in these environments where I know for a fact that the developer has had 40-80 hours of training on memory safety and they still pop up.
If these people have occasional issues, the rest of the world has no effin chance.
I'm afraid your approach would mean hiring someone and spending time and money on them before you're sure they'll work out in your organization. Few want to train contractors and firing FTEs after 3 months and change is a dim prospect as well.
Do training on the things that can cause trouble longer term (inconsistent tooling taking over, security issues, company-specific things you cannot find online) and just hope people pick up the rest as they go. Good workers will usually manage. The people deciding how to train new workers maybe don't even know what kinds of "main" knowledge a given worker would need. Rather than assigning an expensive senior worker to training them, they might hope someone good willing will do it in their spare time.
(I actually don't know what the norm was. My dad was an EE for the defense industry, and IIRC he worked for 3 different employers over his career.)
no wonder so many bugs here and there.
Meta have a phenomenally good training program, called Bootcamp for basically everyone in engineering, so they're probably not the example you're looking for.
Unless it is a “hello world” commit to confirm tooling is operational, I have strong doubts.
When I started at FB in 2013, I had all the laptop/permissions things done by end of the first day.
At the time, the presumption was that you'd push a really small change by the end of the week, but all of the tasks available tended to be pretty easy (note I wasn't in eng then, so all my info is second hand here).
Back in the day people with SVN/CVS commit access would push directly to the main branch after testing locally, and testing would be done as part of preparing a release, so it was more necessary to have a "safety" period where new people could get used to the new codebase.
A: What if you don't and they stay?
I just watched the most recent Last Week Tonight, where they went in depth on Freight Trains [1]. Specifically they talked about 3 mile long trains that currently only have two operators - one conductor and one engineer - and the industry is trying to cut it down to one.
That's just an analogy for software development. But I've definitely seen people be over-worked and under-supported.
Edit.
Idk why downvotes
Chrome and Windows code bases had 70% of cves due to mem issues and their engineers arent some unqualified and lacking of training opportunities ppl