One Rule to Rule Them All
summary
Argues that the single guiding rule is to make it easier to change: correctness is fleeting because requirements and environments accelerate change, so DRY, SRP, tests, VCS and pairing are all special cases of that. Shows a concrete tax example evolving from inline magic number to a rule-driven function and spreadsheet-driven data, and reports fewer surprises after removing heavyweight third‑party libs and writing small parsers (string scanner, recursive‑descent). Prescribes a repeatable habit: write a one‑sentence summary before changing, estimate effort, record actual effort and observations to train intuition, and cut out dependencies where they constrain future change.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:40Agile software development
- 3:47Classic waterfall
- 5:26Theorem proving
- 6:24Correct code
- 9:01Dave's postulate No. 1
- 10:28Change
- 13:21Easy to change
- 14:40How?
- 20:57Dave's postulate No. 2
- 26:35Building intuition
- 30:10Experience
- 34:22Handwrite on paper
- 37:36Make it easier to change
- 38:33Make it fun
- 39:00Q&A
related talks
01h 29m“Simplicity: Not Just For Beginners”
50mRiding the wave of complexity
38mSimplicity: The Key to Software Success
17mThe 5 developers’ principles that helped me as a new father
01h 02mZen and the Art of Code Lifecycle Maintenance
44mCracking the Code Review
26mSimplicity in complexity
38mCompassionate Refactoring
