The clever response to that is: but what if we don't train them and they stay?
I'll say this: programming isn't a profession. If I was being particularly unkind, it's more like a collection of wild west gunslingers.
It probably won't be a profession either until we've settled the whole C++ vs Rust vs Lisp vs JavaScript vs $LANGUAGE_DU_JOUR debate, and stopped acting like egotists. "Rockstar programmer" is a problematical phrase. What it tells us is that programming is one big dick-measuring contest.
I trained as a UK chartered accountant, having graduated in mathematics. I had to go through a set of professional exams. I was under a training contract, started as a junior. I couldn't sign audit reports. That was for the partners. My work was reviewed, and as I moved up through the ranks, I reviewed others. When I was a senior, the juniors asked me for advice. When I finished my work, I spoke to a partner, he reviewed my work, and I reworked whatever was necessary.
There was also "calling and casting". After the accounts were typed up, a more junior clerk would have an old copy of the accounts with corrections, and the more senior clerk would have the revised copy. The junior clerk then read aloud what was on the accounts, and the senior checked it against his copy.
See that? Professional. I imagine lawyers, engineers and manifold other professions have similar appropriate procedures.
What do us programmers do? Release our shit onto the world and fix it later via patches. And issue licences that say we take no responsibility for the fitness of our programs.
That's why I call what we do gunslinging.
Maybe one day the queen will create an Institute of Chartered Programmers, but that day is not only far over the horizon, it's not even in the same solar system.
But I'm not sure I'd want to work in that industry. I like that I can just start hacking away at something that I think will work and create value.
> The clever response to that is: but what if we don't train them and they stay?
Not really. I mean, I get the reference and it is smart. But we're talking about why most tech companies don't hire juniors and train them up. Instead they prefer to hire seniors, not provide any training, and lose them after two years because they can't give pay rises over 5%.
And my impression of "professionals" is not nearly as good as yours. I've seen "professional" managers behave like egotistical idiots way more often than devs. My first startup was destroyed by a "professional" accountant behaving wildly inappropriately. The last time I was a CEO I was quietly informed that I should get a new desk because the previous CEO (an accountant) had a habit of humping hookers on it during his lunch breaks.
I don't see how it's a debate. Different languages have strengths and weaknesses.
> and stopped acting like egotists. "Rockstar programmer" is a problematical phrase. What it tells us is that programming is one big dick-measuring contest.
And yet law is extremely bi-modal. It's not surprising software is similar; you can't argue the average offshored programmer is in any way similar to John Carmack for instance.
> See that? Professional. I imagine lawyers, engineers and manifold other professions have similar appropriate procedures. What do us programmers do? Release our shit onto the world and fix it later via patches. And issue licences that say we take no responsibility for the fitness of our programs.
Sounds like you are hiring wrong. You are hiring programmers and then whine they aren't acting like engineers. Software Engineers have code review, proper release pipelines and methodologies. The bargain-bin programmers don't, of course.
You sorta can.
https://missing.csail.mit.edu/
I've also met grads that basically had a dedicated software engineering class where they learned: What's a package manager, build system, how to compile C++ code (linking and compilation), makefiles, agile, waterfall and source control and a few quality metrics to look out for.
I'm mentoring a new developer at my firm. He's fresh out of college. His code works on a basic level. The things he's stubbed his toes on:
* Naming conventions. We have probably more rules about this than some, but things like branch and commit names matter because we tie them into our issue tracking process.
* Strictly reading specifications. We had a couple days rework because he used a different suggested name for something, and it ended up propagating into dozens of class names.
* Knowing when and what can be cleaned up. This I can forgive, as it normally waits towards the end of the project and he isn't quite there yet, but when we paired to work on it, there was a lot of leftover baggage.
* Bulletproofing/exhaustive coverage. I suspect there's a lot of university projects where "what if the remote server hands us HTTP 418" is answered by "the test service doesn't".
* Multiplayer and advanced Git. "The main branch is going to update without you, and eventually there's going to be merge conflicts" and you'll need to merge/rebase was a problem for him, as was dealing with a feature branch with multiple task sub-branches (keeping too many of them open at once is a huge risk for weird merge conflicts and hideous histories when they're finally resolved).
The non-tech skills of how commercial software development actually works in an actual organisation are really important, and the only way of learning them is on the job.
The best approach would be apprenticeships; learning the craft while doing the job. But the industry has always been ridiculously opposed to training its own staff - echoing your point that this is seen as something that the education system should do (why?).
I've heard managers say crap like "but if we train them then they'll leave us when they finish the training and go somewhere else - we'll have paid for their training and get no benefit". This is a staff retention problem, not a training problem.