I've seen enough code bases that I feel like I have a good spectrum from truly exceptional to horrific. The best code bases had these things in common: 1. Con

I've seen enough code bases that I feel like I have a good spectrum from truly exceptional to horrific. The best code bases had these things in common: 1. Consistency: they had clear patterns that were followed. It doesn't matter what the pattern was; some were strictly object-oriented, some were purely functional, some used RESTful API, and others leveraged gRPC or GraphQL. The important thing was that it was all consistent across the codebase so even if you were looking at a part you'd never seen before you could still orient yourself and reason about it quickly. 2. Ownership: there was always a single individual person who was ultimately responsible for each section of code. That doesn't mean they wrote all the code themselves; they were the final arbiter on the rare occasion a truly contentious conflict arose. They also had the unilateral power to make changes within their section of the code if they felt it was needed. This was always a rarely exercised power but they could, if they had to, push a change through. There could be many such people spread out across the codebase but for each discrete part the number was always one. 3. Clear Boundaries: it was clear what each part of the codebase's purpose was, and the boundaries were rigidly enforced. Things were never tightly coupled across these boundaries. Business logic was always isolated from things like serialization/deserialization, each system was forced to maintain its own models of the world that it cared about. The worst code bases had these things in common: 1. Lack of Eng Representation: Product controlling development schedules and insisting everything is high priority and needs done right now! Project managers who always wonder, "yes but what if 9 women could make a baby in a month. Why don't we try adding more resources? Can we just try?" Business types who see software as a cost center not a profit driver. This can also happen if your engineer leadership didn't come up through software engineering but rather QA or IT or started out in academia or is just plain and MBA type with no eng background. 2. "Time saving" Tech: We don't need a database schema, we can just go NoSQL and have JSON blobs, it will save so much time! We can share models between the front end and back end, it will save so much time! Don't write SQL, use this ORM, it will save so much time! Don't think about DevOps, just use this all in one hosting solution, it will save so much time! What about this low code/no code solution? It will save so much time! 3. Misaligned Incentives: This could be because they were contractors with no stake in the company or this could be because it was a large company and there was no realistic way they'd ever be fired. Either way there were no consequences for writing bad code.