đź’» Coding principles
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.