The thing with core computer science concepts like Big O is not that you need to know them, but that you typically don't realize how much better your code would

The thing with core computer science concepts like Big O is not that you need to know them, but that you typically don't realize how much better your code would be if you did know them (and applied them). I personally have (what I would consider to be a bad) habit of writing a bunch of code with minimal planning upfront, but after it's working I'll review the expected performance of each function and try to optimize as I debug it. There have been times (especially when I'm writing in a new language) where I've written code that works, but missed a spot where it's inefficient and could be significantly improved with a small tweak. The code will run, and in the context of what it's doing it will complete, but it could be made much faster. This has important ramifications if your code is, for example, doing a lot of egress out of AWS, or doing a lot of parsing or data transformation. In situations where the code is not obviously incorrect, it often happens that it's simply not as performant as it could be. It will stay that way, unless a peer reviews the code and spots the inefficiency, or the developer spots it themselves. For small portions of software these individual inefficiencies are not troubling. But there is a real revenue cost to these inefficiencies in production infrastructure if you're doing something more complex than gluing disparate libraries together. I can sympathize with the OP because while I am a big believer in Everyone Gets Code Review (no exceptions), it can be painful for someone to constantly have to fix the same errors over and over again. If the devs on the team in question are motivated to change habits and learn, this won't be a problem. But it could quickly get exhausting to have to fix things on a team over and over again. What will happen if they do not understand e.g. Big O, is the code will work, and every issue will look different to them because they focus on examples, but from the CTO's perspective they'll all be manifestations of the same thing. One will see forest, the other will see trees, and the behavior will be hard to correct. It's also a recipe for low confidence and animosity. I agree with you though that you often don't need this knowledge; i.e. you'll write functioning code without it, and you don't want to prematurely optimize. But you can output better software with fewer unknown unknowns, and Big O is one of them.