Understanding that a "concise, fast, scalable and maintainable" code is not always superior to "complex, slow, unscalable and unmaintainable" code is a big lear

Understanding that a "concise, fast, scalable and maintainable" code is not always superior to "complex, slow, unscalable and unmaintainable" code is a big learning for me over the years. There are tons of "web developers" out there who know some PHP and are charging clients with real money to write really, really bad code for their exotic plants website. They can write their crappy code because they're the only developer and they're only working on some random exotic plants website that gets 500 visitors a day and has 2 database tables with 50 rows. Not that big of a dal. At that point it doesn't matter if they don't have indexes in their tables or know what indexes even are. The single developer is cheap to hire and for the most part get the job done. Clients are happy, developer is happy. Where code like the skull dripping blood or the exotic plants website breaks down is when you try to extend the codebase, scale it or handle more users. It's going to fall flat on its face and you're likely going to have to start over or refactor large portions of the code. That does happen sometimes, but at that point you probably understand your problem domain enough to know what the right features are and rewrite it anyways. So it's not always a bad thing. But when you do the rewrite, you should hire the people who know what they're doing and can write "concise, fast, scalable and maintainable" code.