The Pragmatic Programmer
Main Argument
Good software comes from a set of pragmatic, craft-level habits applied continuously rather than from any single methodology. The two foundations are DRY (every piece of knowledge has one authoritative representation) and orthogonality (components are independent, so change stays local); together they keep systems flexible and cheap to change. Around them sit habits for managing reality: keep decisions reversible because requirements change, build tracer bullets to get end-to-end feedback early, fix broken windows before decay spreads, fail fast when the impossible happens, make assumptions explicit with contracts, and never program by coincidence. The throughline is care: treat software as a craft you continuously invest in.
Key Takeaways
- DRY: duplicated knowledge, not just duplicated code, is the enemy; keep one source of truth.
- Orthogonality: independent, single-responsibility components contain the effects of change.
- Reversibility: there are no final decisions; keep important ones behind abstractions.
- Tracer bullets: build a thin, production-quality end-to-end path early and grow it (distinct from throwaway prototypes).
- Broken windows: fix small decay promptly or entropy accelerates.
- Fail fast: a dead program tells no lies; surface impossible states at their source.
- Design by contract and deliberate programming: make assumptions explicit; never rely on code that merely happens to work.
Concepts Extracted
- dry-principle
- orthogonality
- tracer-bullets
- reversibility
- broken-windows
- fail-fast
- programming-by-coincidence
- design-by-contract
Concepts Enriched
- modular-boundaries (pattern) — fourth source; orthogonality added as a composing concept
Mental Models Reinforced
- design-is-an-investment — third source: continuous care (broken windows, refactoring, DRY) as investment