An aphorism (from Greek ἀφορισμός: aphorismos, denoting ‘delimitation’, ‘distinction’, and ‘definition’) is a concise, terse, laconic, or memorable expression of a general truth or principle.
My aphorisms:
1 - Fewer moving pieces is better. Corollary: unnecessary flexibility is bad.
2 - (stronger) - More than minimum number of moving pieces is bad.
3 - DO care about intent. In code, outside of code.
4 - Late binding is awesome.
5 - Never link to content without significance and context. Answer “Why do I find this worthwhile?” and “Where is this applicable?”.
6 - Consider modeling all possible states as one data type. Fewer edge cases are easier to manage.
7 - When “How does X work?”, consider how your documentation can be improved.
8 - Don’t require hierarchy to be equal to legibility. You will risk creating a Bed of Procrustes.
9 - Emacs is a tool for research. Working with source code is research.
10 - When in doubt, do that which builds trust.
11 - When still in doubt, do that which reifies and distributes intent.
12 - When still in doubt, reduce WIP.
13 - When STILL in doubt, improve your specific & general feedback loops.
14 - Cultivate your taste. Ask yourself what you like. Then ask why.
15 - Good: exploring your taste, aesthetic & values. Bad: comparing yourself with others.
16 - Asking a specific question and generalizing later is often easier than the opposite. Rich, specific context reduces the need for denotation.
17 - Don’t ask people to change their behavior. That is not something they can give you. Instead, ask for something specific they can do to help you now.
18 - When exploring, prioritize cohesion over loose coupling. Explorations should be clearly tied to the initiative they are working for. Keeping the exploration singular ensures clarity and deletability.
19 - Theory should be designed with its application in mind.
Other people whose aphorisms I’ve found to be useful: