The Pragmatic Programmer
Twenty-five years on, most of it holds. The parts that do not are instructive.
Reviewed
The Pragmatic Programmer
Mark
Still the best single book on the craft, provided you read the reasoning and not the rules.
Books about programming age badly, and this one has aged better than almost any of its contemporaries. The reason is that it is mostly about judgement rather than technique, and judgement does not go out of date at the same rate as tools.
What holds up
The core argument — that software is written by people who will forget why, for people who will not ask — is more true now, not less. The chapters on orthogonality and on the cost of duplication describe forces that every codebase I have worked in has obeyed whether or not anyone named them.
The insistence on knowing your tools deeply is the advice I have found most valuable and see followed least. It is unglamorous, it pays back slowly, and it compounds.
What has not aged well
The specific technology advice, unavoidably. Some of the concurrency material predates the problems we actually have now.
More interestingly, the book is written for a world where the individual programmer’s craft was the binding constraint. A great deal of modern software difficulty is organisational rather than personal, and the book has almost nothing to say about that. It is not a flaw so much as a boundary, but it is a boundary worth knowing about before you hand the book to someone as though it were complete.
Reading it now
Read it for the reasoning. The rules are memorable and quotable, which is exactly why they get repeated by people who have not thought about them.