numbered for ease of reference, not for priority

1. code is debt, and bad code is an unhedged call option (a)
   • 
   • our users dont care about the code
   • every line of code has costs (your time, readability, maintainability, complexity)
   • its like owning a house with lots of rooms. its nice when your friends come over once a month, but you pay rent every day
   • dont add features prematurely
   • another perspective (a)

2. DRY DRY DRY actually DAMP (a) is better

3. keep it simple (a), especially at first

4. be consistent

5. no magic! be predictable

6. no magic numbers/strings — use constants instead

7. a good repro is 90% of a bugfix

8. code is written once, but is read many times

9. ship early, ship often

10. first code, then ship, then measure, then optimize

11. remember the 80/20 rule, and the 90/90 rule

12. design layers of abstraction with deep modules (a)

13. prefer encapsulated complexity (a)

14. write tests. not too many. mostly integration. (a)

15. comments should describe what’s not obvious (a). i used to hate comments but this book (a) changed my mind.

16. Postel’s law is wrong — be strict both ways

17. budget your innovation tokens (a)

18. tools, not rules. e.g. go fmt (a)

19. RAT, not MVP (a)

20. first you don’t know the rules, then you learn the rules, then you break the rules

See also: programming principles, hacker laws (a), Dieter Rams’ principles (a), the Zen of python (a), Urbit precepts (a)

old version here