pragmatic-programmer

The Pragmatic Programmer

Apply this skill to day-to-day software design, coding-practice, debugging, and requirements questions using the Pragmatic Programmer's checklist-style principles, drawn from the 2019 20th Anniversary (2nd) Edition.

Core concepts

DRY — Don't Repeat Yourself — Every piece of knowledge (not just code text) should have a single, unambiguous, authoritative representation in the system. Duplicated logic, duplicated data schemas, duplicated documentation-vs-code all count. When reviewing code or a design, look for knowledge duplication, not just copy-pasted lines.

Orthogonality — Design components so a change in one has no ripple effect on unrelated ones. Ask "if I change this, what else could break that has no logical connection to it?" Low orthogonality shows up as fragile systems where small changes cause surprising failures elsewhere.

Reversibility — Avoid decisions that are hard to undo (a specific vendor, a rigid architecture, a hardcoded assumption) when a reversible alternative is available at similar cost. Not every decision needs maximum flexibility — but flag when a design bakes in an assumption (a database choice, a third-party API) that will be expensive to change later.

Tracer bullets & prototypes — For unclear or risky requirements, build a thin end-to-end skeleton that actually runs (a tracer bullet) to get real feedback fast, as opposed to a throwaway prototype meant to explore/discard one specific unknown. Know which one the situation calls for: tracer bullets get kept and built on; prototypes get thrown away once they've answered their question.

Broken windows & boiled frogs — Visible small decay (a broken window: sloppy code, a "TODO" left too long, a hacky workaround) signals that decay is acceptable and invites more of it — fix it or explicitly flag/timestamp it. "Boiled frog" is the danger of not noticing gradual degradation because no single step looks alarming — periodically zoom out and reassess from scratch.