Simplicity-oriented programming
1. Abstractions are most often more expensive than whatever you are trying to prevent by adding an abstraction
2. Indirections are most often more expensive than whatever you are trying to prevent by adding an indirection
3. Dependencies are most often more expensive than whatever you are trying to prevent by adding a dependency
4. Complexity hidden behind a procedure call is complexity nonetheless
5. Architecture emerges from code, not the other way around
6. Most things are simple to change. Data structures are not. Consider them carefully.
7. Thinking about computer programs from a very high level or in an overly abstract manner is most often unhelpful
8. All programs are, in essence, a set of instructions operating on data. Reasoning that strays too far from this definition is most often unhelpful.
9. Architectures or design patterns with a fancy name and a catchy abbreviation are most often extraordinarily unhelpful
10. If you value simplicity, then if someone is getting paid in any way for giving you programming advice, you most likely shouldn't listen to that advice
11. If you value simplicity, then you should stick to the fundamentals and avoid most trends, particularly those that promise to be revolutionary
12. Files and packages exist to split code at meaningful interfaces, not to keep things neat and aesthetically pleasing. If long files or a flat file hierarchy are causing you trouble, you need a better text editor
13. Your workflow needs to be simplicity-oriented too. If you are constantly waiting for an IDE to stop lagging or for a build to finish, it's hard to get anything done
14. Over time, most simple code degenerates into complex code. Whenever it happens, that code needs to be revisited promptly, because complexity spreads quickly