Book Note: The Pragmatic Programmer Part 6 - Reduce Coincidence While Coding

The Pragmatic Programmer Part 6 - Reduce Coincidence While Coding

Code is not finished just because it runs. If I do not understand why it works, coincidence becomes debt in the next change.

■ How to use this note

This is part 6 of an eight-part reading series on The Pragmatic Programmer. It covers Chapter 6 · While You Are Coding.

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

L0 · Entry

• Core idea: The most dangerous moment while coding is when the code runs but I still do not understand why.
• 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: Programming by Coincidence, Algorithm Speed, Refactoring, Code That’s Easy to Test, Evil Wizards
• Question: How do we turn code that merely appears to work into code we understand?

L1 · Captures

• This chapter can be read through the question: How do we turn code that merely appears to work into code we understand?
• Useful English terms: programming by coincidence · refactoring · testability
• I avoid long quotations here and use paraphrase because the source is a copyrighted book.

L2 · Chapter Map

Scope	My label	Core question
Chapter 6 · While You Are Coding	Reduce Coincidence While Coding	How do we turn code that merely appears to work into code we understand?

Programming by coincidence means leaning on a success we have not observed carefully. Algorithmic thinking turns performance intuition into a measurable shape. Refactoring improves structure while preserving behavior. Testable code is usually well-separated code. Wizard-generated code is dangerous when trusted without understanding.

L3 · Insight Cards

1. AI-generated code deserves extra suspicion of coincidence

LLM output can look plausible and run once. Without verification, AI simply accelerates programming by coincidence.

2. Deferred refactoring consumes feature work later

A structure left messy today becomes the cost of the next feature. Refactoring is not the opposite of feature work; it keeps feature work possible.

3. Testability is a thermometer for design

Code that is hard to test often hides dependencies and unclear responsibility. Tests are design feedback.

L4 · Production Board

• Add a verification note to AI-generated code explaining why it is correct.
• Separate Big-O thinking from actual measurement in a performance issue.
• Put a behavior-preserving test in place before refactoring.

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: The most dangerous moment while coding is when the code runs but I still do not understand why.

Next

• Previous: Part 5
• Next: Part 7
• Back to bookshelf: /book