Book Note: The Pragmatic Programmer Part 2 - Remove Duplication, Design for Change

The Pragmatic Programmer Part 2 - Remove Duplication, Design for Change

Chapter 2 looks like a collection of design techniques, but underneath it is one question: where do we leave room for future change?

■ How to use this note

This is part 2 of an eight-part reading series on The Pragmatic Programmer. It covers Chapter 2 · A Pragmatic Approach.

I use the same operating principle as my Korean notes: notes are storage, insight cards are currency.

L0 · Entry

• Core idea: Good design does not preserve today’s answer in amber; it leaves room for tomorrow’s change.
• Why I picked this book: as AI writes more code, I want a clearer standard for what the developer still has to judge, explain, and verify.
• Initial assumption: I expected an older collection of programming advice. What remains is closer to an operating system for professional judgment.
• Scope: The Evils of Duplication, Orthogonality, Reversibility, Tracer Bullets, Prototypes and Post-it Notes, Domain Languages, Estimating
• Question: How can we build software that can change without pretending to finish everything upfront?

L1 · Captures

• This chapter can be read through the question: How can we build software that can change without pretending to finish everything upfront?
• Useful English terms: DRY · orthogonality · tracer bullets
• I avoid long quotations here and use paraphrase because the source is a copyrighted book.

L2 · Chapter Map

Scope	My label	Core question
Chapter 2 · A Pragmatic Approach	Remove Duplication, Design for Change	How can we build software that can change without pretending to finish everything upfront?

DRY is not a slogan against copy and paste. It protects a single source of knowledge. Orthogonality keeps one change from shaking the whole system. Reversibility prevents today’s decision from closing tomorrow’s options. Tracer bullets and prototypes reduce uncertainty through working feedback rather than argument.

L3 · Insight Cards

1. DRY targets duplicated knowledge, not just duplicated code

The deeper risk is not two similar functions. It is the same policy growing differently in several places.

2. Orthogonality is central to an AI-agent harness

If tools, prompts, data, and validation are tangled together, one agent failure can collapse the whole loop. Separation makes repair possible.

3. A tracer bullet is direction, not completion

A thin working path through the system reveals reality faster than a beautiful plan. Blog automation needs that same end-to-end pulse.

L4 · Production Board

• Find two places where the same rule is stored twice.
• Separate prototype code from production code.
• Build the next automation as a thin end-to-end tracer bullet first.

Prompt template

Review the following software task through The Pragmatic Programmer lens.
1. Find duplicated knowledge, hidden coupling, and unclear responsibility.
2. Separate what humans are remembering from what can be automated.
3. Suggest three small improvements I can apply today.
4. Define the verification harness needed before delegating this to an AI agent.

L5 · Review

This chapter connects to Clean Code, Refactoring, and my current LLM Wiki experiment. The durable question is not which tool is fashionable, but how a developer chooses, changes, verifies, and communicates work.

• Open question: when AI generates more of the code, where does pragmatic responsibility move?
• Final takeaway: Good design does not preserve today’s answer in amber; it leaves room for tomorrow’s change.

Next

• Previous: Part 1
• Next: Part 3
• Back to bookshelf: /book