Rules for software developers, honed over 40 years.
These are rules to follow which were garnered by 40 years of software development experience. The rules themselves are succinct and condense deep truths. Click through on any rule to find the reasoning behind it — the rationale is rarely obvious at first glance.
The rules are deliberately opinionated
They reflect a personal software development philosophy, honed often through painful experience. The rules are language agnostic — applying them is always important, but becomes even more important as your development language becomes less constrained. Consistently following them leads to good professional practice: over time it becomes ingrained, like muscle memory, and becomes "the way you roll". You lose the temptation to cut corners, because the way you normally roll is faster and better than corner cutting.
Your colleagues and your future self will thank you for following the rules.
Start here
Each rule links through to a full explanation of the reasoning behind it, and a practical summary of how to apply it.
There are no shortcuts
Technical debt is unavoidable — but good professional practice is the fastest path to delivery, not the slowest.
→ 02All code is first-class code
Code exists primarily to convey a technical solution to other people's minds. Test code deserves the same quality as application code.
→ 03Code for other people, not just for the solution
Program with intent — good comments, clear names, and DocBlocks are how you explain what the code was meant to do.
→ 04Avoid stream of subconsciousness programming
Pouring thoughts into the editor with no prior consideration of intent leaves a codebase no one can safely change.
→ 05Security is your responsibility
Security is the primary non-functional requirement. As a developer, it's on you — not someone else's team.
→ 06Always test first
Testing is nearly impossible to reverse-engineer well — write it first, so it's always in place protecting your code, your application and your customer.
→ 07Test functionality, not implementation
Test the contract your code makes with its caller, so the implementation is free to change without ever touching the test suite.
→ 08Test business rules and aim for 100% coverage
Give your business rules one source of truth, and let it drive your tests, for the confidence to refactor or rewrite and trust the system still works.
→