The Pragmatic Programmer: find mistakes while they are cheap

The integration is almost finished when someone opens an actual supplier file. Product identifiers lose leading zeros, some rows repeat, and a negative quantity means a return in one system but an error in the other. The team built a screen, selected storage and wrote a scheduler before checking what the data supporting its plan actually meant.

This fictional failure helps explain why I recommend The Pragmatic Programmer. Its value lies in improving decisions during development: investigating assumptions, obtaining feedback and reducing the cost of correcting direction. The benefit depends on turning memorable advice into specific experiments. Calling an approach pragmatic does not explain which risk was investigated or why the solution fits its circumstances.

The revised edition under discussion

This review covers The Pragmatic Programmer: Your Journey to Mastery, by David Thomas and Andrew Hunt, the twentieth-anniversary second edition, published in 2019, ISBN 9780135957059. The Addison-Wesley/InformIT catalog identifies it as a revision of the 1999 book, with new topics and examples. This is not an assessment of the first edition.

Its arrangement into relatively independent topics suits reading alongside real work. You can study an idea, try it and return with a more precise question. I recommend resisting the urge to turn the advice into a mandatory checklist for every project. The value of its range is that it supplies different questions for different problems, including tools, testing, requirements and coordination.

Among the ideas discussed here, I find its attention to duplicated knowledge, independence between parts and the distinction between learning from a prototype and building a version that will remain particularly useful. They connect through one concern: how much work will a mistaken assumption force us to repeat?

DRY concerns knowledge that must change together

The official DRY extract explains duplication in terms of knowledge and intent, including across code and documentation. The authors acknowledge that their earlier explanation allowed an interpretation limited to copying and pasting code. That clarification is a specific reason to pay attention to the revised edition.

Suppose an application accepts batches containing at most a thousand rows. If its screen, importer and manual independently record that limit, a change requires remembering three places. A shared contract or generated documentation can reduce inconsistency. The question is which representation has authority and how the others are derived or checked.

Two validators accepting the same character sequence today might have different reasons. One handles product codes and another handles customer identifiers. Merging them because their text looks similar could force unrelated areas to evolve together. I would keep the repetition until the knowledge really was shown to be the same. The cost of a mistaken abstraction will surface in subsequent changes too.

This reasoning extends to tests. A test obtaining its expected result by calling the very function under examination can repeat an error consistently. Some acceptance examples need independently chosen values. Centralizing a rule should not remove every opportunity to notice that its implementation is wrong. A single source of authority still needs meaningful verification.

Orthogonality and reversibility need concrete questions

The authorized tip collection for the anniversary edition includes independence between parts, openness to change and verification of assumptions. My application of orthogonality would be to ask whether changing an input format requires changing decisions unrelated to that format. A new inventory-file delimiter should not alter import authorization.

That may justify separating file reading, business validation and presentation. Separation carries costs, so I would check whether each part actually hides a decision. Placing the same sequence in five classes that share global state is unlikely to create independence. The useful criterion is how a change propagates, not how many boxes appear in the diagram.

Reversibility must include data and users. Replacing a parser before importing any batches differs from correcting thousands of published records. A database choice can be reconsidered, but migration costs work, compatibility decisions and risk. I would translate the advice into preparing samples, versioning contracts and delaying effects that are difficult to undo until behavior is better understood. Keeping options open becomes cheaper when the team recognizes where those options become expensive.

A disposable prototype and a tracer bullet promise different things

The authors explain prototypes and a minimal path through a system in The Art in Computer Programming, a 2001 essay predating the reviewed edition. I use it to clarify a distinction also present in the second edition's organization: an experiment can be discarded after producing knowledge, while a tracer bullet establishes a path that will be extended.

For the supplier example, an isolated script can check whether the parser preserves identifiers in test files. A synthetic sample provides controlled inputs without authentication or scheduling. Investigating the supplier's actual encoding and format requires a representative sample from that supplier or a confirmed contract. The useful result records what each experiment supports. That does not automatically make the script a candidate for production service code.

A first slice intended to remain requires different care. It crosses receipt, parsing, validation and presentation, with narrow scope and observable behavior. It may accept only one format and one item type, but should not depend on shortcuts the team intends to forget. Confusing small scope with temporarily unsafe behavior is one way a prototype quietly becomes production software.

I would record which kind of work we are doing, what we expect to learn and who decides what happens next before starting. That helps prevent a visually convincing demonstration from becoming a promise of a complete delivery. Both techniques reduce uncertainty, but they leave different artifacts and maintenance obligations.