If I had to summarize what properties make up good code, it would be simplicity and ease-of-change.

Making code easy to change means nailing separation of concerns.

Spaghetti code that’s separated or combined in a manner where significant changes are usually isolated is great code.

In fact, I’d say that DRY is one of the most counter-productive principles to follow in all but trivial situations.

So much of the “well architected” code we write is actually just speculation embedded as a commitment.

All other software qualities (testability, portability, reliability, efficiency, etc) can be more easily achieved with code that is quick to understand and modify.

Coding principles I’ve found most valuable

• Names should protrude meaning. `isStarted` contains more information than `start`.
• Comment the why (time saver => value boost), not the how (mostly noise), except when optimizing.
• Tests/Linters/CI/CD == sanity.
• Allow duplication to emphasize the right abstraction (don’t rush DRY-ness).
• Most problems can be solved by adding a layer of indirection.
• Write code for humans. Use tools to translate to the machine (Short code != better code).
• Be empathetic in your API designs. Make it easy for people to do the “right thing”.
• Data should be immutable by default, mutable by need.
• Automate the things machines do better (and faster) than humans.
• Untamed flags/switches tend to compound over time and create a combinatorial increase in complexity.
• State/context boundaries should be well-established and strictly respected.
• Conversations between services should happen in small groups.
• Don’t just write extensible code, write deletable code.
• Future proof by making the code inherently easy to change (loosely coupled)
• Pretty much anything you think about the future will be wrong. Don’t try to anticipate every possible way it might change.
• Tools come and go. The biggest value isn’t in remembering their quirks but in understanding their approach.