The Pragmatic Programmer book club questions

1. 1.

   Which broken windows have you left in a codebase you work in? What stopped you from fixing them at the time?

2. 2.

   Thomas and Hunt argue that duplication is the root of most maintenance problems. Where in your current project is knowledge duplicated, and how did that happen?

3. 3.

   Think about your 'knowledge portfolio' as a developer. Which skills are you investing in this year, and which ones are depreciating without your noticing?

4. 4.

   The tracer bullet approach suggests building thin end-to-end slices before filling in detail. When have you seen this work well, and when does it break down in practice?

5. 5.

   The book argues that good developers make their tools their own. What's the last tool or workflow you invested serious time in customizing? Did it pay off?

6. 6.

   How do you currently handle estimation in your team? Do you feel the estimates you give are honest, and what happens when they're wrong?

7. 7.

   The authors say good code is 'easy to change.' Think about code you've written or maintained. What made it easy or hard to change, and would you make different decisions now?

8. 8.

   The 'stone soup' story is about making change happen without authority. Have you ever done this successfully in an organization? What made it work?

9. 9.

   Where in your career have you blamed a tool, a language, or a requirement instead of finding a way around it? Looking back, was there a better path?

10. 10.

    Thomas and Hunt emphasize owning outcomes rather than just intentions. In software teams, where does the line between individual and collective ownership break down?

11. 11.

    The book recommends learning a new language every year. Is that realistic for you? What would you lose and gain by diversifying your technical knowledge more aggressively?

12. 12.

    If a new developer on your team read this book, which single piece of advice do you think would change their work the most? Why?

How to run the discussion

• Pick six to eight, not all of them. An hour of real discussion covers fewer questions than anyone expects, and racing the list is what makes a book club feel like homework.
• Open with what people noticed, not what they concluded. Asking for a verdict first hardens opinions before anyone has heard each other.
• Let the disagreement run. The questions below that split a room are the ones worth the time; the ones everyone answers the same way can be skipped.
• Ask the quiet person a specific question. A direct, narrow question is far easier to answer than an open invitation to contribute.