Guidelines for Zen Development

zendevelopment.md

Written by Michael Pratt - Inspired by The Codeless Code

Guidelines for Zen Development

These aren't rules, merely guidelines. The order isn't meant to imply a ranking of importance. Some conflict with each other - this is not a defect, but a reminder that developers often have conflicting requirements. It is up to you to determine how to compromise.

1. Minimize magic.
2. A clever solution is not always a good one.
3. A popular solution is not always the best one.
4. The ideal solution is not always worth the effort.
5. If something seems hard, make sure you aren't doing it wrong.
6. Short, clear code hides fewer bugs.
7. A non-functional line of code is a bug waiting to happen.
8. Keep code golf out of production.
9. Copying is not a substitute for understanding.
10. Bugs and limitations in third-party code are still your problem.
11. Mastery comes not from knowing how to use a tool, but when and why.
12. Reusable code is better than duplicated code.
13. Be nice to your future self; write simple and obvious code.
14. Even simple code does not self document.
15. If you really need to comment every line, your code is too complicated.
16. There are only three numbers: 0, 1, and N.
17. Don't let progress get in the way of process.
18. Deployment automation is great, but don’t become complacent.
19. What code style you follow for a project isn't as important as simply following one.
20. Don’t suggest a change to the style guidelines unless you’re prepared to implement it.
21. You are not the technologies you use.
22. If it’s an important project, use a technology you know well.
23. Your design should be flexible, but you should still think it out in full.
24. "Design twice, develop once” doesn’t generally work out in practice.
25. Rewrites can be costly, but they are easier done earlier.
26. Be prepared to defend your coding decisions. If you can’t, you should have done it differently.
27. Be willing to question others’ code. If you won't, you shouldn’t be reviewing it.
28. Don’t take code reviews personally. No one is perfect.
29. Seniority, wisdom, and age are not strongly correlated.
30. A dozen mistakes, once each, is learning. The same mistake, a dozen times, is failure to learn.
31. You cannot measure the value of a developer solely by analyzing the code they write.
32. Don’t code around problems to hide them.
33. Fix your own bugs and you’re less likely to repeat them.
34. New bugs should result in new tests.
35. Fixing a bug and ending up with two new bugs means you probably had three bugs to begin with.
36. Eliminate suspected race conditions. Don’t wait for a bug to appear.
37. Even test code can have bugs.
38. Intermittent test failures means there is a bug in the test.
39. If your tests fail, your build should fail.
40. 100% code coverage isn't always feasible, but more coverage is still always better.
41. Good code coverage is not neccesarily indicative of good testing.
42. Caffeine is a poor substitute for sleep.