Book notes: The Pragmatic Programmer, 20th Anniversary Edition

These are my notes on David Thomas and Andrew Hunt's The Pragmatic Programmer, 20th anniversary edition.

The original version was in my "must read" list for any software developer, and this update version one is no different.

Key insight: After reading the new edition, I have come to realize of how huge an impact the first edition made on my career. I can see that most of my advice is rooted in this book.

It is also nice to see how the authors have come to the same conclusions regarding functional programming (Clojure style) and OO that I have. From the "transforming programming" section:

• All programs transform data, converting input into an output.
• When we think of programs as something that transforms input into output, many of the details we previously worry about just evaporate. The structure becomes clearer, the error handling consistent and coupling drops way down.

See Dave Thoma's YOW! keynote for a longer explanation.

You can find all the tips here.

Key Insights

• You own your life.
• Good enough software.
• Most important strategic asset: learn to learn.
• A team that doesn't continuously experiment with their process is not an agile team.
• Tip 76: Programmers help people understand what they want. > Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Antoine de Saint-Exupéry, Wind, Sand and Stars 1939.
• Try it.
• How will you know that we've all been successful after this project is done?
• Moral compass:
  1. Have I protected the user?
  2. Would I use this myself?

TOC

• Preface
• 1 - Pragmatic Philosophy
• 2 - A Pragmatic Approach
• 3 - The Basic Tools
• 4 - Pragmatic Paranoia
• 5 - Bend, or Break
• 6 - Concurrency
• 7 - While You Are Coding
• 8 - Before the Project
• 9 - Pragmatic Projects
• Postface

Preface

• There is no best solution.
• Tip 1: Care about your craft.
• Tip 2: Think about your work.
• Software is engineering with individual craftsmanship.
• Kaizen: continuous improvement, every day.

Chapter 1 - Pragmatic Philosophy

• You own your life.
• Team trust is essential.
• Provide options, not excuses.
• Tip 5: No broken windows.
• People find it easy to join an ongoing success.
• Good enough software.
• Most important strategic asset: learn to learn.
• Your knowledge is the most important asset.

Chapter 2 - A Pragmatic Approach

• Tip 14: Good design is easier to change.
• Programmers are constantly in maintenance mode.
• Tip 18: There are no final decisions.
• Tip 20: Tracer Bullets (aka. walking skeleton).
• Tip 21: Prototype to learn.
• Learn what you see risk in.
• Keep a log of your estimates, find out why went wrong for those with > 50% of error.

Chapter 3 - The Basic Tools

• Tip 25: Keep knowledge in plain text.
• Keep an engineering daybook.

Chapter 4 - Pragmatic Paranoia

• Crash, dont trash.
• Leave assertions on in production.
• Tip 42: Take small steps - Always.

Chapter 5 - Bend, or Break

• Tip 45: Tell, dont ask
• Events:
  • Finite state machines.
  • PubSub
  • Reactive programming.
• All programs transform data, converting input into an output.
• When we think of programs as something that transforms input into output, many of the details we previously worry about just evaporate. The structure becomes clearer, the error handling consistent and coupling drops way down.
• Big reason that OO systems are hard to change: encapsulation.

Chapter 6 - Concurrency

• Agents.
• Blackboards.

Chapter 7 - While You Are Coding

• When stuck, give yourself a break.
• Tip 34: Dont assume, prove it.
• Dont let existing code dictate future code.
• Tip 65: Refactor early, refactor often.
• TDD FTW.
• Property-based testing FTW.

Chapter 8 - Before the Project

• Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Antonie de St. Exupery, Wind, Sand and Stars 1939.
• Tip 75: No one know what exactly what they want.
• Tip 76: Programmers help people understand what they want.
• Tip 78: Work with a user to think like a user.
• The only requirements document is working code.
• Tip 80: Use a project glossary.
• A team that doesn't continuously experiment with their process is not an agile team.

Chapter 9 - Pragmatic Projects

• Tip 84: Maintain small, stable teams.
• Tip 85: Schedule it to make it happen.
• Team speaks with one voice to the rest of the org.
• Generate a team brand.
• Good communication: instant and frictionless.
• Try it.
• How will you know that we've all been successful after this project is done?
• Tip 97: Sign your work.

Postface

• Moral compass:
  1. Have I protected the user?
  2. Would I use this myself?
• Tip 99: Dont enable scumbags.

Comments

[Manuel Odendahl]

Another transformative book, and in my top 5 as well! You have a similar taste in books than I do :)