"An investment in knowledge always pays the best interest."
Personal notes, key takeaways, and mental models from The Pragmatic Programmer: 20th Anniversary Edition by Andrew Hunt & David Thomas.
| Chapter | Title | Status |
|---|---|---|
| Intro | Introduction | ✅ Done |
| 01 | A Pragmatic Philosophy | ✅ Done |
| 02 | A Pragmatic Approach | ✅ Done |
| 03 | The Basic Tools | 🔲 Pending |
| 04 | Pragmatic Paranoia | 🔲 Pending |
| 05 | Bend or Break | ✅ Done |
| 06 | Concurrency | 🔲 Pending |
| 07 | While You Are Coding | 🔲 Pending |
| 08 | Before the Project | 🔲 Pending |
| 09 | Pragmatic Projects | 🔲 Pending |
notes/- Chapter-by-chapter notesconcepts/- Deep dive on important ideasexamples/- Code and practical examplesquotes.md- Memorable quotes
- 1. It's Your Life — You own your career, do something about it.
- 2. Take Responsibility — When things go wrong, be honest and direct. Provide solutions, not excuses.
- 3. Software Entropy — Broken windows left unrepaired spread decay. Fix them immediately.
- 4. Stone Soup and Boiled Frogs — Don't wait for permission. Deliver something good, let people join the success.
- 5. Good-Enough Software — Great software today beats perfect software tomorrow. Know when to stop.
- 6. Your Knowledge Portfolio — Your knowledge is you most important asset.
- 7. Communicate — Ideas without effective communication are orphans. Know your audience, listen, get feedback.
- ETC — Easier To Change —
- DRY — Don't Repeat Yourself —
- Orthogonality —
- Reversibility —
- Tracer Bullets —
- Prototypes —
- Domain Languages —
- 28. Decoupling — Minimize what each component knows about others; keep code shy.
- 29. Juggling the Real World — Model state and reactions with FSMs, Observer, Pub/Sub, and reactive streams.
- 30. Transforming Programming — Treat programs as pipelines that transform data, not sequences of instructions.
- 31. Inheritance Tax — Favor interfaces, delegation, and mixins over inheritance.
- 32. Configuration — Externalize config and expose it behind an API for dynamic, shared use.
- The Stone Soup Story
- The Broken Window Theory
- Domain Specific Languages (DSL)
- Functional Programming
- Config Server Pattern
- Event Driven Architecture
Key tips from chapters covered so far. Updated as reading progresses.
Tip 1: Care About Your Craft — Always develop quality products and services.
Tip 2: Think About Your Work — No auto-pilot, constantly be thinking on what your are doing while you are doing it.
Tip 3: You Have Agency — You have the power to act, choose, and shape outcomes.
Tip 4: Provide Options, Don't Make Lame Excuses - If you don't know something, admit it, then rapidly learn and solve it.
Tip 5: Don't Live with Broken Windows - Fix bad designs, wrong decisions, and poor code as soon as you find them. Don't let rot normalize.
Tip 6: Be a Catalyst for Change - Work with what you have. Prove something is possible, and others will follow.
Tip 7: Remember the Big Picture - Constantly review what is happening around you, not just what you personally are doing.
Tip 8: Make Quality a Requirements Issue — Define quality explicitly, involve users in that definition, and use it as your stopping criterion.
Tip 9: Invest Regularly in Your Knowledge Portfolio — Consistent, diversified learning compounds over time.
Tip 10: Critically Analyze What You Read and Hear — Don't accept things at face value. Think about who is saying it, why, and whether it holds up against your own experience. The tech industry is full of hype, fads, and vendor-driven narratives. Develop your own informed perspective.
Tip 11: English is Just Another Programming Language — Treat written and verbal communication with the same care you give your code.
Tip 12: It's Both What You Say and the Way You Say It — The same message delivered differently can inform, motivate, or alienate.
Tip 13: Build Documentation In, Don't Bolt It On - Documentation written after the fact is incomplete and often wrong. Embed it in your development process from the start: inline comments, ADRs, OpenAPI specs, READMEs. It will save far more time than it costs.
Tip 14: Good Design Is Easier To Change Than Bad Design —
Tip 15: DRY - Do Not Repeat Yourself —
Tip 16: Make It Easy to Reuse —
Tip 17: Eliminate Effects Between Unrelated Things —
Tip 18: There Are no Final Decisions —
Tip 19: Forgo Following Fads —
Tip 20: Use Tracer Bullets to Find the Target —
Tip 21: Prototype to Learn —
Tip 22: Program Close to the Problem Domain —
Tip 23: Estimate to Avoid Surprises —
Tip 24: Iterate the Schedule with the Code —
Tip 25: Keep Knowledge in Plain Text —
Tip 26: Use the Power of Command Shells —
Tip 27: Achieve Editor Fluency —
Tip 28: Always Use Version Control —
Tip 29: Fix the Problem, Not the Blame —
Tip 30: Do not Panic —
Tip 31: Failing Test Before Fixing Code —
Tip 32: Read the Damn Error Message —
Tip 33: "select" Is not Broken —
Tip 34: Dot not Assume it, Prove It —
Tip 35: Learn a Text Manipulation Language —
Tip 36: You Cannot Write Perfect Software —
Tip 37: Design With Contracts —
Tip 38: Crash Early —
Tip 39: Use Assertions To Prevent the Impossible —
Tip 40: Finish What You Start —
Tip 41: Act Locally —
Tip 42: Take Small Steps - Always —
Tip 43: Avoid Fortune Telling —
Tip 44: Decoupled Code Is Easier to Change —
Tip 45: Tell, Don't Ask —
Tip 46: Don't Chain Method Calls —
Tip 47: Avoid Global Data —
Tip 48: If It's Important Enough to Be Global, Wrap It in an API —
Tip 49: Programming is About Code, But Programs Are About Data —
Tip 50: Do Not Hoard State; Pass It Around —
Tip 51: Do Not Pay Inheritance Tax —
Tip 52: Prefer Interfaces to Express Polymorphism —
Tip 53: Delegate to Service: Has-A Trumps Is-A —
Tip 54: Use Mixins To Share Functionality —
Tip 55: Parameterize Your App Using External Configuration —
(More tips added as chapters are completed)
Notes by a backend engineer and tech lead with experience in Java, Spring Boot, microservices, and cloud-native systems on Azure/Kubernetes. Reading this book to sharpen software design instincts — not just coding skills.
If these notes help you, consider ⭐ starring the repo.