97 Things Every Programmer Should Know collective wisdom from the experts (Kevlin Henney)（Z-Library）

# 97 Things Every Programmer Should Know ## 【One-Line Pitch】 A collection of 97 concise, practical essays from leading software practitioners covering the craft of programming—from coding techniques and design principles to career habits and team dynamics. Perfect for working developers who want bite-sized wisdom they can apply immediately, or anyone looking to broaden their perspective on what it means to be a professional programmer. ## 【Book Arc】 - **Opening (~0%–10%)**: The book opens with a table of contents organized by themes—design principles, coding techniques, testing, users and customers, and career development. This structure signals that the book is meant to be browsed rather than read cover-to-cover, with each essay standing alone. - **Early (~10%–25%)**: The first essays establish core values: simplicity as the foundation of beautiful code, the importance of context when reusing code, and the humility to check your own code before blaming tools. These pieces set the philosophical tone for the collection. - **Early–Middle (~25%–40%)**: The focus shifts to concrete coding practices—writing code in the language of the domain, expressive layout, compact formatting, and encapsulation principles. This section reads like a style guide from experienced practitioners. - **Middle (~40%–60%)**: Essays address professional habits and team dynamics: deliberate practice as distinct from mere task completion, the importance of deployment processes, maintaining code health, and handling exceptions responsibly. The tone becomes more reflective about the developer's role. - **Late (~60%–100%)**: The collection continues with testing philosophy, tool mastery, and interpersonal skills—covering topics like writing tests for people, knowing your IDE, and understanding that testers are your friends. The book closes with essays on continuous improvement and the broader craft of programming. ## 【Key Takeaways】 - **Simplicity is the foundation of all code quality** (Early): Readability, maintainability, and beauty all stem from simplicity, not complexity. This Platonic ideal applies regardless of whether you approach code as art or science. - **Context matters more than reuse** (Early): Pulling out shared code without understanding whether the similarity is accidental or intentional creates hidden coupling. Two pieces of code that look the same may need to evolve independently. - **Check your own code before blaming the compiler** (Early): Compiler and OS bugs are extremely rare in mature tools. The time spent proving the tool is wrong is almost always better spent finding your own error. - **Code should speak the language of the domain** (Early): When code expresses business rules in domain terms, it becomes self-documenting and easier to evolve as understanding grows. The programmer who maintains your code later might be you. - **Encapsulation is about narrow interfaces, not hiding data** (Early–Middle): Don't ask objects for information to work with—ask objects to do the work with the information they already have. Setters and getters that expose internal state are liabilities. - **Deliberate practice is different from task completion** (Middle): The goal of deliberate practice is improving your ability, not finishing the task. Experts typically require around 10,000 hours of focused, repetitive practice to achieve mastery. - **Deployment should be designed from the start** (Middle): The installation process is the first thing customers see. Testing deployment on clean environments periodically prevents assumptions that rely on development environments. - **Code health requires continuous attention** (Middle): Refactoring, reducing dependencies, and eliminating corner cases should be ongoing hygiene tasks. A "hygiene list" of worthwhile cleanup projects reduces future expenses and speeds releases. ## 【Reading Tips】 - **Skim the table of contents first** and jump to topics that address your current challenges—this book is designed for browsing, not linear reading. - **Deep-read the essays on encapsulation and domain language** (around 20%–35% of the book) if you want the most actionable coding techniques; these are the densest with practical advice. - **Pay attention to the author attributions**—essays from well-known practitioners like Uncle Bob Martin and Udi Dahan often carry the most weight, but lesser-known contributors sometimes offer surprising insights. - **Treat each essay as a discussion starter** rather than gospel; the book deliberately presents diverse viewpoints, and some advice (like the "Beware the Share" essay) directly contradicts common wisdom. - **Skip around freely**—if an essay doesn't resonate, move on. The 97 pieces are independent, and the value comes from finding the ones that speak to your situation. ## 【Coverage Limits】 This guide is based on approximately 22 of the book's 32 indexed chunks, covering roughly the first 60% of the content. The excerpts do not cover the later essays on testing philosophy, tool mastery, and career development in detail, though their titles are visible in the table of contents. ##