The ones that were straightforward and close to the business. It starts at the obvious, works in an obvious way and has comment blocks at hard parts. For this

The ones that were straightforward and close to the business. It starts at the obvious, works in an obvious way and has comment blocks at hard parts. For this reason I despise most modern [web] projects, which have a weak start, immediately drop into “services” and “components”, do one action per source file per 30-50 lines of code, which are mostly imports and boilerplate, and have hundreds of these files. You can never tell what it does because it does almost nothing except formalities. I also noted a tendency to use wrong paradigms for a language. E.g. it may have no closures (imagine that in 202x) so they use events as continuations for asynchronicity, which results in a mess. Or it isn’t immutable/functional, but they pretend it is, which results in fragility. The best projects are both close to their business and written in a paradigm of the language used. Was there someone enforcing good practices top down? Natural time pressure is the best bs cleaner, imo. You write effing code, maybe have few hours a week to refactor strange parts. With no time pressure a project naturally becomes massaged by all members into the “likeable” form of their age.