This is a classic mistake that relatively junior people make. There's a body of research out there that goes back more than half a century that gives you plenty

This is a classic mistake that relatively junior people make. There's a body of research out there that goes back more than half a century that gives you plenty of heuristics, metrics, and other ways to classify code as good at bad in all sorts of interesting ways. Most engineers have barely any awareness of this and instead absorb vague notions of "good" and "bad" things from others over time. Junior frontend engineers coming fresh out of college are typically very ignorant on this front. Ignorant as in they have yet to rediscover this wealth of information through reading books, articles, etc. As well as by messing up a few code bases or by absorbing it from their more senior peers through e.g. code reviews or venting on blogs, twitter, and whatnot. That is because this stuff just isn't taught in a lot of places. Or if it is taught at all, it isn't taught very well typically by people who don't do a lot of coding. I know, because I used to be such a person before I switched to doing some actual software engineering 20+ years ago. Combined with the arrogance of youth and the tendency to label everyone above 27 as a senior, unclean code is rather common. And even acknowledging it is bad is a problem when you lack the intellectual tools to reason about code quality. It's not a matter of taste to consider high coupling and low cohesiveness a bad thing. It's easy to see when that is out of wack (long list of imports, 4000 line source files, etc.). It's easy to measure as well if you care too but typically redundant to do so. Likewise, having a high level of indirection would be a violation of e.g. Demeter's law. Likewise deep inheritance hierarchies aren't great (just don't). And that is equally easy to observe. Finally having a large function with insane nesting of loops, ifs, and what not produces a high complexity that you can measure or just look at it an go "gee, this looks rather complicated". It's not that hard to spot bad code if you know what to look for. It's also not that hard to improve such code once you understand why it is bad. Every bad code base you've ever seen probably has a lot of things that you can objectively point at and say this just isn't very clean because X. It stops being a matter of esthetics when you phrase it like that. And the broken windows theory combined with a level of ignorance/indifference usually leads to more bad code making it into the code base. There are plenty of studies that will suggest that having a lot of hard to read code does not help maintainability, extensibility, and a few other -ilities. Those are called quality attributes. And yes, you trade them off sometimes. There are yet more studies that point to maintenance as a dominant thing in overall software cost. There are also several standards that have lots of things to say about quality attributes. People developing e.g. embedded software for cars or medical devices tend to take that stuff rather seriously. But understanding that high cost is bad is relatively uncontroversial. Producing code that isn't very clean leads to higher cost. It's not about the esthetics but about cost. Both current and future. Sometimes you can trade that cost off. E.g. if you are going to throw away your UI code in 6 months, it's OK to put a few cheap fresh out of college people on that project. It's going to be a dumpster fire in terms of code quality but it might be useful as an MVP and you'll replace it anyway before it gets out of hand. I make tradeoffs like that all the time. And I also use such projects as an opportunity to train up young people quickly. Let them make a few mistakes and then show them how to fix it.