Author: Andrew Hunt and David Thomas · Published: 1999 · Genre: Programming, Software Engineering
The Pragmatic Programmer‘s biggest strength is breadth: in one readable volume it covers the habits, attitudes and tools that separate a professional developer from someone who merely writes code. Its biggest weakness is the flip side of that breadth, a scattershot collection of short tips that rarely goes deep, some of which read as common sense to experienced engineers. It is the best first book on the craft for junior and mid-level developers.
The core ideas
Hunt and Thomas, who two years later were among the signers of the Agile Manifesto, organized the book as short topics, each distilled into numbered tips: 70 in the original, 100 in the 20th anniversary edition of 2019.
- DRY, Don’t Repeat Yourself. The book coined the term. Every piece of knowledge should have a single, authoritative representation in a system. The point is knowledge, not identical lines: a business rule restated in code, a database constraint and a document violates DRY even if no text is copied.
- Broken windows. Software rot starts with one ignored hack or bad design. Fix it, or at least board it up with a comment or stub, before neglect spreads.
- Orthogonality and reversibility. Keep components independent so a change in one doesn’t ripple through others, and avoid decisions you can’t undo, because vendors, platforms and requirements change. The 2019 edition puts one value at the center of all this: good design is easier to change than bad design.
- Tracer bullets. Build a thin, working end-to-end slice of the real system early and grow it, instead of perfecting one layer at a time. Unlike a prototype, which you throw away, tracer code is kept.
- Take responsibility. Offer options, not lame excuses (the book’s example is “the cat ate my source code”), manage a knowledge portfolio by learning at least one new language a year, and master your tools: plain text, the shell, your editor and version control.
What’s great
- Metaphors that stick. Stone soup, where you win support by starting something small and letting people join in, and the boiled frog, which fails to notice slow change, are easy to remember and apply.
- Debugging sense. The book is where rubber duck debugging gets its name: explain the problem line by line to a duck and you’ll often spot the bug. It also warns that “select” isn’t broken, meaning the bug is almost always in your code, not the operating system or library.
- Programming by coincidence. Code that works for reasons you don’t understand will fail for reasons you don’t understand. Crash early, use assertions and state your contracts instead of hoping.
- A real update. The 2019 edition is heavily rewritten, with new material on security and concurrency, and clarifies that not all duplicated code is duplicated knowledge.
What’s weak
The format that makes the book easy to read also keeps it shallow. Most topics get a few pages, so you’ll need other books, such as Refactoring or Code Complete, for depth. Several tips, such as caring about your craft and thinking about your work, are platitudes that experienced developers won’t need.
The advice is drawn from the authors’ experience, not from evidence, and it is occasionally stated with more confidence than it deserves. DRY in particular has been misread by a generation of developers as a ban on any repeated code, leading to premature abstractions that tie unrelated parts of a system together. The first edition’s tool recommendations and examples are also clearly late 1990s.
Who should read it
Developers in their first few years will get the most out of it, and it makes a good gift for a new hire. Get the 20th anniversary edition (2019), not the original. Senior engineers can skim the table of tips and read only what’s new to them.
Rating: 4/5
Image credits — Featured image: Image by lejoe via Flickr, CC BY 2.0, cropped. In-article images: Photo by sadaf amininia on Unsplash.
