- Always think how to simplify the code you write, since simple code is easier to maintain and debug.
- Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored.
- Always think about improving the usability of the software product you work on. Users don't care about code. They care about UX of your product.
- Fix small usability issues as soon as you notice them, since these issues are usually the most annoying for end users.
- Do not start writing code with some popular design patterns. Just write the most simple code, which resolves the given task. Later, the best design patterns will evolve organically from the code solving the particular task.
I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of.
I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with life and let the business keep moving.
For writing simple code, I often remind people that the first working code is not the one to commit.
Just like a text draft is edited, once the code works, now is time to trim it and simplify it.
- Always think how to simplify the code you write, since simple code is easier to maintain and debug.
- Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored.
- Always think about improving the usability of the software product you work on. Users don't care about code. They care about UX of your product.
- Fix small usability issues as soon as you notice them, since these issues are usually the most annoying for end users.
- Do not start writing code with some popular design patterns. Just write the most simple code, which resolves the given task. Later, the best design patterns will evolve organically from the code solving the particular task.
VictoriaMetrics development goals are based on these rules - https://docs.victoriametrics.com/goals/