S - Simple Is never simple as people can just not at all agree on what simple means. Even experienced programmers. This isn't even a question of training. It's

S - Simple Is never simple as people can just not at all agree on what simple means. Even experienced programmers. This isn't even a question of training. It's deeply embedded into human nature due to peoples thought process differing and in turn what they find simple. P - Performant While a certain baseline performance does matter often (not always) anything beyond that yields increasingly diminishing returns. Discarding even large chunks of performance in rarely run non time critical code in favor of otherwise "better" code can sometimes be a very good decision. Somewhat derived from "simplicity" and readability but not any less important is making code easy to change (by literally changing it, not by making it configurable or parametrized). The problem with DRY and similar isn't that it's bad practice but that people take it too far and try to have rules they can just always blindly strictly always apply ignoring imperfections of e.g. other tools they use. For example DRY is about not repeating "business logic" (1) but people try to forcefully apply it to language structure and things which just happen to be similar. They then often do so by using abstractions which make future changes to the code harder by put constraints on about what is possible. Another common failure is to not diverge (i.e. copy) you code when business logic diverges through a change of requirements but instead try to handle it by additional parameterizeation/genericity often using means which make the code again harder to change. I.e. TL;DR: DRY isn't bad but like most things it's not a rule you can blindly apply but a tool/skill you need to learn to properly use, including when to not use it. (1): What counts as "business logic" differs depending on the abstraction level/context you are looking at the code; That doesn't make it easier to use.