>> about how a code base "is crap" > Translation: "Not written in the particular arbitrary style that I'm used to" > I've found this to be almost universally tr

>> about how a code base "is crap" > Translation: "Not written in the particular arbitrary style that I'm used to" > I've found this to be almost universally true especially when the claim is given forcefully but not immediately backed up with a litany of actual user-impacting serious problems. There's certain code smells that most experienced developers are going to identify that would be almost universally considered bad. Things like poor variable/method/class names, use of magic values, duplicated logic, high coupling, and lack of unit tests. None of these have immediate user-impacting problems, and arguing that's the only thing that matters is very short-sighted. All of these issues will slowly degrade a codebase over the long term -- as the requirements change, new developers start working on the code, and bugs compound other bugs -- and the user impact will be slower delivery and lower quality. Eventually the code will get to a point where the only save is a major rewrite which causes even slower delivery and higher risk of regression in both features and bugs. Writing good variable names at the time the code is created is significantly easier than fixing it months later. Writing the code in a way that can be unit tested is easier up front (and sometimes impossible later, without a rewrite and all the dangers that go with that). There's also a big difference between a code base that's maintained by the same focused person (or small group) for a long time, vs being one of several code bases maintained by a team of people (who may change over time). In the former you can get away with things you can't in the latter case, and moderately or highly successful small projects tend to shift to the latter, and are the ones people will call crap code bases despite their commercial or user-facing success.