Book Note: The Pragmatic Programmer Part 7 - Clarify the Question Before the Project

The Pragmatic Programmer Part 7 - Clarify the Question Before the Project

A project begins succeeding or failing long before the first commit. We need to read requirements, change questions, and respect the feeling that we are not ready yet.

■ How to use this note

This is part 7 of an eight-part reading series on The Pragmatic Programmer. It covers Chapter 7 · Before the Project.

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

L0 · Entry

• Core idea: A good question before the project can remove many meetings during the project.
• 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 Requirements Pit, Solving Impossible Puzzles, Not Until You’re Ready, The Specification Trap, Circles and Arrows
• Question: What must become clear before the project starts so that failure costs less later?

L1 · Captures

• This chapter can be read through the question: What must become clear before the project starts so that failure costs less later?
• Useful English terms: requirements · specification trap · readiness
• I avoid long quotations here and use paraphrase because the source is a copyrighted book.

L2 · Chapter Map

Scope	My label	Core question
Chapter 7 · Before the Project	Clarify the Question Before the Project	What must become clear before the project starts so that failure costs less later?

Requirements are mined, not delivered as finished truth. Impossible puzzles can become solvable when constraints are reconsidered. The feeling of not being ready can signal missing information rather than laziness. Specifications and diagrams are communication tools, not substitutes for reality.

L3 · Insight Cards

1. Requirements are traces of conversation, not just sentences

A written requirement can hide the real user constraint. Good developers translate and ask again.

2. An impossible puzzle is a signal to change the question

A blocked problem may not need more force. It may need a different framing of the constraint.

3. Specifications should become harnesses

If a specification does not lead to code and verification, it becomes document storage. A good spec lets people and agents act against the same standard.

L4 · Production Board

• Write three real user actions before starting a new feature.
• Turn one impossible constraint into a question.
• Attach a verification method to each major requirement.

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: A good question before the project can remove many meetings during the project.

Next

• Previous: Part 6
• Next: Part 8
• Back to bookshelf: /book