Rules of Pragmatic Programming:

0. Steal the best rules from other systems where it doesn't increase the number of rules past 10 and the new rule is considered worthy. Attack the rules frequently so that only the best rules survive. All of these rules are suggestions to be applied only in moderation. The world is gray and messy, its behavior cannot at this time be reliably and completely predicted. The rules are language and philosophy agnostic to the extent that a given language or philosophy tolerates the rules, so even though this is hypothetically a schism from functional programming, actual functional programming for example is tolerable if applied thoughtfully.

1. Code gets read way way more frequently than it gets written, write code with the intent that it should be easy to read. Here is how I do it:

• Make things small and simple and let them do only one thing.
• Make things as predictable as possible.
• Names of things should contain just enough but not too much information. This is not expected to be easy.
• If the names of things describe things, and if it is hard to name something, then that thing defies description and warrants attention.
• Comments are frequently indicators that the names and organization of the code could use more love. Comments are a threat to readability because they are easy to neglect and not update when the code changes.

2. In writing, you must kill all your darlings. Code will not reciprocate your love. Personal or emotional investment in a potential solution to a problem is frequently bad news.
3. Premature Optimization kills.