Enter the “rule of three” — the actually actionable, pragmatic principle that elegantly combines how you should be thinking about YAGNI, DRY and premature optimisation. The rule of three states that you should only refactor (or optimise) code once you’ve written the same code three times.

At the first time of writing the code, code that’s fast and optimized is great, but if it’s hard to read and reason about, it will slow us down in the long run. Here, I like to apply another principle: “Make it work, make it right, make it fast”

It works while iteration though. In some cases, you want to leverage engineering: make it right the first pass. It happens for API validation for example, or logging correctly in case of failure.

Gall's law: a complex system that works is invariably found to have evolved from a simple system that worked

Functions should be as idempotent as possible: all it really means is that a function always does the same thing when given the same arguments. Note idempotent functions are different from pure functions. pure functions are guaranteed to not have side effects.

Then there is this single responsibility principle. It avoid changes on the entire codebase. "A small trick to check for single responsibility is to describe what a function/module/class does in a single sentence. If you find yourself saying “and”, then it probably has multiple responsibilities and should be split up."

One efficient implementation is to operate on one level of abstraction. See a function implemented in three functions. I would still be critic on this one, because the tradeoff is not worth it from time to time.

These code principles are similar indeed. "All good code is alike; each bad code is bad in its own way."