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