The Pragmatic Programmer

The book's argument is that the defining property of good software is not correctness at a moment but the ability to be changed safely afterwards. Requirements move, understanding improves, and the code that survives is the code that can absorb that.

Everything else follows. The practices are not presented as a system to adopt wholesale but as a set of habits a working programmer can pick up individually, which is why the book has outlasted most of the methodologies it shared a decade with.

Software is judged less by whether it works today than by how safely it can be changed tomorrow.

Devmark’s reading — not a quotation from the book

The opening essays are about professional stance rather than technique: provide options rather than excuses, and do not leave broken windows — small visible defects that signal nobody is minding the codebase and license the next one.

The broken-windows metaphor is the book's most quoted idea and its most useful organisational observation. Quality degrades by permission, not by accident, and the permission is granted by the first tolerated mess.

Don't Repeat Yourself is the book's most famous acronym and its most misapplied. The authors' formulation is about knowledge: every piece of knowledge should have a single, unambiguous, authoritative representation in a system.

It is not a rule against similar-looking code. Two fragments that coincide today but change for different reasons are not duplication, and merging them creates a coupling that will have to be undone. The test is whether they would have to change together.

Orthogonality is the property that changing one thing does not require changing unrelated things. The authors treat it as the practical measure of good structure, because it determines the blast radius of any change.

Reversibility is the companion: avoid decisions that cannot be undone, and be suspicious of the phrase "there is only one way to do this". Much of the book's architectural advice is about keeping the number of irreversible commitments low.

A distinction worth keeping. A prototype is disposable and built to answer a question. A tracer bullet is a thin but complete path through the whole system — real code, kept and grown — built to check that the parts connect and to give everyone something visible early.

The authors are firm that confusing the two is expensive, because a prototype promoted into production carries all the shortcuts it was allowed to take.

A prototype answers a question and is thrown away. A tracer bullet is thin, real, and kept.

Devmark’s reading — not a quotation from the book

A long practical thread runs through the book: master a single editor, learn the shell, use version control for everything, learn one scripting language well enough to automate anything you do twice.

The point is leverage. Time spent removing friction from the ten operations you perform hourly returns more than almost any other investment, and the authors are unusual in treating this as a professional obligation rather than a preference.

Hunt and Thomas import design by contract from Eiffel: preconditions, postconditions and invariants stated explicitly, so responsibility for correctness is assigned rather than assumed.

The related advice is to crash early. A program that continues after an impossible state has been detected will fail later, further from the cause, and with the evidence gone. Defensive code that quietly swallows a problem is worse than no defence at all.

The chapters on estimation are notably unromantic. Estimates should carry units that communicate their own precision — "about a quarter" says something different from "90 days" — and should be revised in public as they are learned.

The authors are also good on scope: the observation that requirements rarely arrive, they are gathered, and that a client's stated requirement is usually a proposed solution to an unstated problem.

The twentieth-anniversary edition rewrote a substantial portion. The language examples were modernised, the concurrency material expanded, and the sections on testing and property-based approaches strengthened. Some advice that had become universal — use version control — is now framed as assumed rather than argued.

The stance did not change. If anything the revision confirms which parts of the original were technique and which were judgement, because only the technique needed updating.

It is a book of maxims, and maxims travel poorly without judgement. DRY applied without thought produces the wrong abstraction; orthogonality pursued without limit produces a fog of indirection. The authors know this and say so, but the aphoristic form makes the caveats easy to skip.

It is also individualistic. Its unit is the practitioner, not the team or the organisation, and it has comparatively little to say about the structural forces that produce bad software in otherwise capable teams.