Eight rules, condensing 40 years of experience
If you click through on a rule you'll find the reasoning behind it, which may not be immediately obvious, followed by a practical summary of how to apply it.
There are no shortcuts
Software development creates technical debt the way trees create oxygen — unavoidable, but reducible through good professional practice.
→ 02All code is first-class code
If code fails to convey a technical solution to other people's minds, it is poor and potentially dangerous code — test code included.
→ 03Code for other people, not just for the solution
Say what your code is going to do, up front. If you don't program with intent, your source files are just a stream of your consciousness.
→ 04Avoid stream of subconsciousness programming
Reading such code is like being transported into someone else's dream — boundary conditions unhandled, failure modes unconsidered.
→ 05Security is your responsibility
Security is the primary non-functional requirement. Make sure it's built into your build and deployment pipeline, not bolted on after.
→ 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, not its internal mechanics, so the implementation is free to change without ever touching the test suite.
→ 08Test business rules and aim for 100% coverage
One source of truth for your business rules should drive your tests. 100% coverage with a green build buys you the confidence to refactor, or even rewrite the application, and trust it still works.
→Now AI writes most of the code
These rules don't get less true — but AI changes where each one bites. A practical guide to applying them when the author of your code is a model, not a person.