There is substantial domain knowledge you require to code safely.
Explain someone who hasn't been exposed to how numbers are represented in memory that doing financial stuff with IEEE 754 floating point numbers (default in JavaScript and others) can lead to precision errors, with possible financial consequences. Very hard to do without going all the way to the basics.
Or maintainability, security, configuration, construction for verification, performance, scalability, concurrency, thread-safety... and all non-functional requirements.
You can save money in less skilled people. I have fixed bugs implemented by self-taught guys. I remember profiling a service experiencing service degradation (with terrible financial consequences) and finding a O(2^n) function that could be O(1). That's the kind of risk you expose yourself to.
Teaching non-coders to code isn't primarily about getting them to do core engineering work, although I personally love the idea that that could happen over time for ones who wanted it. These classes don't have folks implementing feature requests for our payments APIs; they're largely producing side projects so that they understand the world their engineer coworkers live in every day.
Also, if O(2^n) code made it into production, that isn't a failure of the programmer, that is a failure of the system.
We want to be serious and rigorous about engineering process, because bugs at Stripe could affect a lot of peoples' livelihoods. Accordingly we implement things like code reviews, automated testing, and performance monitoring. We make substantial efforts on all of these, and they improve the quality of output for all developers, including both ones who picked up coding late in life and ones who've been coding since age six, have a CS degree, and certainly implemented an O(2^n) function at their first job [+].
Other companies doing meaningful things should also be placing their bets as to process improvements as to reduce failure. "Hire only people who don't make mistakes" seems to be a hard bet to win with.
[+] I'd never point fingers at anyone for this since it is entirely natural but since it was me I feel less guilty about it.
Teaching non-coders to code is not going to produce productive engineers except in the most unusual circumstances. You're introducing people to concepts like a terminal, a file system, source code, a text editor, variables, subroutines, debugging...
After a few weeks, they understand more about what it's like to craft instructions for an incredibly powerful but incredibly stupid machine. That doesn't understand what you want it to do and always takes you literally.
After that experience, they understand the rhythm and routines of engineering more intuitively and are better prepared to collaborate effiiciently with engineers.
Learning is good. I am OK with people going outside of their comfort zone and learning about other disciplines, it helps people empathize, appreciate the effort of others, it facilitates collaboration, etc.
But we don't say: doctors make a lot of money, I am going to go to a doctor camp and learn to think like a doctor in 12 weeks! Then I will work as a full-stack doctor and become rich! But replace doctor with some software engineer and suddenly it makes sense.
Some people argue that we don't do life and death stuff, just harmless friendly websites. But one careless mistake can result in personally identifiable information being leaked for millions of people. Do that in healthcare and it's a HIPAA violation with only 1 single record instead of millions and you can get fired with your license revoked.
Then, I am not saying or implying "hire people who don't make mistakes". Everyone makes mistakes. Even the top 1% of top performers make mistakes.
The difference is how those mistakes happen and why. Mistakes can come in all forms, because we make assumptions and sometimes those assumptions can be wrong. The reason we can make fast decisions is because the human brain simplifies problems by making assumptions. But the assumptions made by a trained person are different.
Well realistically, someone could become a reasonably functional, useful doctor in 12 weeks, but the problem is they'd kill people pretty frequently. Bad programmers just write bad code, so if you're building a stupid website it's a lot less bad when it goes wrong.
depends how big n gets in the context of that particular function. a O(2^n) can be faster real world that O(1) if the overhead of the O(1) is bigger than the O(2^n) version. Its important to remmeber that big O is a measure of worst case as n grows. If N is bounded by the realities of the business case, it might not be so bad.
Thinking in absolutes doesn’t make justice to your described position. There are certainly at least few people who are self-taught and are better at something that you do.
On the other hand "self-taught" people are often strongly motivated, intellectually curious and adaptable. Moreover, long lists of credentials and degrees don't guarantee that silly mistakes won't be made.
Explain someone who hasn't been exposed to how numbers are represented in memory that doing financial stuff with IEEE 754 floating point numbers (default in JavaScript and others) can lead to precision errors, with possible financial consequences. Very hard to do without going all the way to the basics.
Or maintainability, security, configuration, construction for verification, performance, scalability, concurrency, thread-safety... and all non-functional requirements.
You can save money in less skilled people. I have fixed bugs implemented by self-taught guys. I remember profiling a service experiencing service degradation (with terrible financial consequences) and finding a O(2^n) function that could be O(1). That's the kind of risk you expose yourself to.