97 Things Every Programmer Should Know: Collective Wisdom from the Experts
Programming is often taught through syntax, algorithms, frameworks, and projects. But becoming a truly good programmer requires much more than knowing how to write code. It requires learning how to think about software, communicate with users and teammates, test ideas, maintain existing systems, choose appropriate tools, and continuously improve your engineering practices.
97 Things Every Programmer Should Know: Collective Wisdom from the Experts, edited by Kevlin Henney, is a collection of short essays that explores these broader aspects of professional programming. Published by O'Reilly in 2010, the book contains 97 contributions from experienced programmers and software practitioners. The O'Reilly edition is listed as 255 pages, while the ebook edition is listed at 258 pages.
The book is deliberately different from a traditional programming textbook. It does not teach one programming language or framework. Instead, it presents practical advice and principles that can be applied across programming languages, projects, teams, and technologies.
Download the PDF for free:
97 Things Every Programmer Should Know: Collective Wisdom from the Experts (Free PDF)
What Is the Book About?
The central idea behind the book is simple: good programming is a craft.
Knowing syntax is only the beginning. A programmer also needs to understand how software behaves over time, how code affects other developers, how users interact with applications, and how seemingly small technical decisions can create long-term consequences.
The 97 essays cover topics such as:
Code quality
Simplicity
Testing
Refactoring
Software design
APIs
Databases
Algorithms
Data structures
Version control
Continuous learning
Debugging
Automation
User experience
Team collaboration
Professional development
The official contents include topics such as "Code Is Design," "Code Reviews," "Continuous Learning," "Deploy Early and Often," "Don't Repeat Yourself," "Improve Code by Removing It," "Put Everything Under Version Control," "Read Code," "The Single Responsibility Principle," and "Use the Right Algorithm and Data Structure."
Why This Book Is Different from a Programming Textbook
A conventional programming book may teach you:
def calculate_total(price, tax):
return price + price * tax
But knowing how to write this function does not answer larger engineering questions.
Should the function be this small?
Should the tax calculation be separated?
How should the function be tested?
What happens if the input is invalid?
Will another developer understand the function six months later?
Should the function name reflect business terminology?
Should the behavior be documented?
These are the kinds of questions that distinguish writing code from engineering software.
That is where this book becomes useful.
The Book Is About Programming Beyond Syntax
One of the strongest themes throughout the collection is that programming is not simply about making a computer execute instructions.
Software exists to solve problems.
That means programmers need to understand:
Users
Business requirements
Domain concepts
System constraints
Technical trade-offs
Maintenance
Team communication
The book's essays encourage programmers to think about all of these dimensions rather than focusing exclusively on implementation.
Code Is Design
One of the important topics in the book is the idea that code itself represents design.
Design is sometimes treated as something that happens before programming begins.
In reality, implementation decisions continuously shape the architecture of a software system.
Choosing:
A class structure
A function boundary
An API
A database model
An abstraction
A module structure
is also a design decision.
This means developers should not think of coding as simply translating an already-finished design into syntax.
The code is part of the design.
Why This Matters
Poorly designed code can make future changes difficult.
For example, imagine a Python application where one enormous function handles:
User authentication
Database operations
Email notifications
Payment processing
Report generation
Even if the program works, maintaining it will become increasingly difficult.
Breaking responsibilities into meaningful components can make the system easier to understand and modify.
This is why software design and code quality are deeply connected.
Beauty Is in Simplicity
Another recurring lesson is the value of simplicity.
Programmers sometimes create complicated solutions because complicated solutions appear more sophisticated.
But complexity has a cost.
Every unnecessary abstraction can increase:
Maintenance effort
Cognitive load
Debugging difficulty
Testing requirements
Onboarding time
A simpler solution is often easier to understand and change.
This does not mean that every program should be simplistic.
The goal is appropriate simplicity.
A good programmer learns to distinguish between complexity that is necessary and complexity that exists only because of poor design.
The Boy Scout Rule
One of the well-known ideas associated with the book is the Boy Scout Rule.
The principle is commonly summarized as leaving the code in a slightly better condition than you found it.
Imagine opening an old function and noticing:
A confusing variable name
Unnecessary duplication
Poor formatting
An outdated comment
Instead of ignoring everything because "it was already like that," a developer can make a small improvement while working in the area.
Over time, many small improvements can significantly improve a codebase.
This is particularly useful in large and long-lived projects.
Why Small Improvements Matter
Software quality rarely improves through one gigantic cleanup operation.
Large refactoring projects can be risky and expensive.
Small, continuous improvements are often easier to review and integrate.
The idea is:
Touch code → Understand it → Improve it → Leave it cleaner
This creates a culture of continuous improvement.
Don't Repeat Yourself
The book also includes the familiar principle Don't Repeat Yourself, commonly known as DRY.
The fundamental idea is that duplicated knowledge creates maintenance problems.
Consider:
price = quantity * unit_price
If the same business rule is duplicated across ten different locations, changing that rule later becomes difficult.
However, DRY should not be interpreted as "never write similar-looking code."
Two pieces of code may look similar while representing different business concepts.
The deeper lesson is to avoid duplicating knowledge and responsibility, not simply identical lines of syntax.
Testing Is a Core Engineering Practice
Testing receives substantial attention throughout the book.
The contents include topics such as:
Testers Are Your Friends
Test for Required Behavior Not Incidental Behavior
Test Precisely and Concretely
Testing Is the Engineering Rigor of Software Development
Write Tests for People
Testing is not merely about checking whether a program currently works.
Good tests can also communicate what the software is supposed to do.
For example:
def add(a, b):
return a + b
A test such as:
assert add(2, 3) == 5
does more than verify a calculation.
It also communicates expected behavior.
Testing as Documentation
Well-designed tests can act as executable documentation.
A developer reading:
assert calculate_discount(100, 10) == 90
can immediately understand one expected behavior of the function.
This is particularly useful when requirements are complicated or when the original developer is no longer working on the project.
Code Reviews
Code review is another important software-engineering practice represented in the book.
A code review provides an opportunity for another developer to examine changes before they become part of the system.
Reviewers may identify:
Bugs
Security issues
Poor naming
Duplicated logic
Architectural problems
Missing tests
Unnecessary complexity
But effective code reviews should not become competitions about who knows more.
The objective is to improve the software.
A Good Code Review Culture
A healthy review process focuses on questions such as:
Does the code solve the problem?
Is the design understandable?
Is it tested?
Could it introduce a regression?
Will future developers be able to maintain it?
This creates a collaborative engineering environment rather than a personal criticism system.
Continuous Learning
Technology changes rapidly.
Programming languages evolve.
Frameworks become obsolete.
New architectures emerge.
Development tools improve.
The book includes Continuous Learning among its topics, reinforcing the idea that professional programmers need to keep developing their knowledge.
Continuous learning does not necessarily mean learning every new framework.
Instead, programmers should develop durable fundamentals while selectively learning technologies that are relevant to their work.
For example, a Python developer might focus on:
Python → APIs → Databases → Testing → Git → Cloud → AI/ML
rather than attempting to learn every programming language available.
Learn More Than One Language
The book also contains Know Well More Than Two Programming Languages.
Learning multiple languages can expose developers to different programming paradigms and ways of thinking.
For example:
Python emphasizes readability and flexibility.
JavaScript provides a strong foundation for web development.
Java emphasizes object-oriented and enterprise programming.
C provides insight into lower-level programming and memory.
Functional languages can introduce different approaches to state and computation.
The objective is not to collect programming languages as trophies.
The objective is to expand your understanding of programming itself.
Know the Language's Culture
Learning syntax is not enough.
Every programming language has its own ecosystem, conventions, idioms, tools, and community practices.
For example, Python programmers commonly value readability and idiomatic simplicity.
A programmer who knows Python syntax but ignores Python conventions may still write technically valid code that feels unnatural to experienced Python developers.
Understanding a language's culture therefore becomes part of becoming proficient in that language.
Choose Your Tools with Care
Modern developers have access to thousands of tools.
Editors, IDEs, libraries, frameworks, databases, cloud services, testing tools, CI/CD platforms, containers, and AI assistants can all improve productivity.
But tools should solve problems rather than create unnecessary complexity.
A good question is not:
"What is the newest tool?"
Instead:
"What problem am I trying to solve?"
This prevents technology choices from becoming driven purely by trends.
Know Your IDE and Command-Line Tools
The book also emphasizes practical development skills such as knowing your IDE and command-line tools.
This may seem less exciting than learning a new framework, but productivity often depends heavily on how efficiently a developer can navigate their development environment.
Understanding features such as:
Debugging
Search
Refactoring
Navigation
Code inspection
Version-control integration
Terminal commands
can save enormous amounts of time.
Automation
The book repeatedly highlights automation.
Automation can remove repetitive manual work from development workflows.
For example:
Manual testing
→ Run tests one by one
versus
Automated testing
→ Run the entire test suite automatically
Similarly:
Manual deployment
→ Developer performs deployment steps
versus
Automated CI/CD
→ Pipeline builds, tests, and deploys automatically
Automation allows developers to spend more time solving meaningful problems.
Deploy Early and Often
The book includes the principle Deploy Early and Often.
This challenges the idea that software should remain hidden until everything is perfect.
Early deployment can reveal:
Integration problems
Performance issues
User misunderstandings
Infrastructure limitations
Unexpected edge cases
The earlier these problems become visible, the less expensive they can be to fix.
This principle connects naturally with modern practices such as:
Continuous Integration
Continuous Delivery
Continuous Deployment
Automated Testing
Put Everything Under Version Control
Version control is one of the most fundamental practices in software development.
A version-control system allows developers to track changes and collaborate safely.
Git is now widely used for this purpose.
A simple workflow might look like:
Create branch
↓
Make changes
↓
Run tests
↓
Commit
↓
Push
↓
Code review
↓
Merge
Version control also provides historical information.
If something breaks, developers can investigate what changed.
Without version control, tracking the evolution of a project becomes much harder.
Read Code
Writing code is only part of a programmer's job.
Developers spend substantial amounts of time reading:
Existing applications
Libraries
APIs
Documentation
Pull requests
Logs
Tests
Configuration files
The book includes Read Code as a dedicated topic.
Learning to read unfamiliar code is therefore a critical programming skill.
Why Reading Code Is Difficult
Writing new code gives you control over the structure.
Reading existing code means entering someone else's mental model.
You need to determine:
What does this code do?
Why was it written this way?
What assumptions does it make?
What depends on it?
What could break if I change it?
These questions are central to maintenance and debugging.
Improve Code by Removing It
More code does not necessarily mean better software.
Every additional line creates another opportunity for:
Bugs
Complexity
Maintenance
Testing
Misunderstanding
Sometimes the best improvement is removing unnecessary code.
For example, if a complicated implementation can be replaced with a simpler standard-library function, the resulting system may be easier to maintain.
This is an important mindset shift:
Programming is not about maximizing the amount of code you write.
It is about creating the simplest reliable solution to the problem.
Use the Right Algorithm and Data Structure
Performance often depends more on the algorithm and data structure than on small code-level optimizations.
For example, searching for an item in a list generally requires different work from checking membership in a set.
Conceptually:
items = [1, 2, 3, 4, 5]
and:
items = {1, 2, 3, 4, 5}
represent different data structures with different characteristics.
Understanding:
Arrays
Lists
Sets
Dictionaries
Trees
Graphs
Queues
Stacks
helps developers choose appropriate solutions.
The book explicitly includes Use the Right Algorithm and Data Structure among its 97 topics.
Comments Should Add Meaning
The book also discusses comments and emphasizes that comments should explain things that the code itself cannot communicate clearly.
Consider:
# Add 1 to count
count += 1
This comment adds little value because the code already communicates the operation.
A more useful comment might explain why something unusual is being done.
For example:
# API returns timestamps in UTC, so convert before comparison.
The code may not make that business or technical assumption obvious.
This leads to a useful rule:
Use code to explain what. Use comments to explain why.
Think About the User
One of the book's listed topics asks:
"What Would the User Do?" — You Are Not the User.
Developers naturally understand their own software differently from first-time users.
A developer may know exactly where a feature is located.
A new user does not.
Therefore, assumptions based on the developer's own behavior can be misleading.
Good software development requires observing actual users and understanding their workflows.
This is especially important for:
Web applications
Mobile applications
SaaS products
Forms
Dashboards
APIs
Developer tools
Code Is Written for the Future
One of the most practical lessons in the book is the importance of writing code that other people can understand and maintain.
The book includes:
Write Code As If You Had to Support It for the Rest of Your Life
This is a powerful mindset.
Instead of asking:
"Can I make this work?"
ask:
"Will someone else understand this six months from now?"
That changes programming decisions.
You start paying greater attention to:
Naming
Structure
Tests
Documentation
Error handling
Simplicity
Dependencies
Professional Programming
The book also includes The Professional Programmer as one of its topics.
Professionalism in software development is not simply about technical ability.
It also involves:
Taking responsibility
Communicating clearly
Meeting commitments
Learning from mistakes
Respecting teammates
Writing maintainable software
Understanding business requirements
Thinking about users
A programmer can write highly optimized code and still be ineffective if they cannot collaborate with others.
Who Should Read This Book?
Beginners
Beginners can use the book to develop good habits early.
However, it works best when read alongside actual programming practice.
Intermediate Programmers
Intermediate developers may get even more value because they already have enough experience to recognize the problems discussed in the essays.
Experienced Developers
Senior developers can use the essays as reminders and discussion starters.
Some ideas may feel familiar, but revisiting familiar principles from a different perspective can still be useful.
Software Engineering Students
Students can use the book to complement technical courses on programming languages, algorithms, databases, and software engineering.
Developers Switching Languages
Because the advice is largely language-independent, the book is useful when moving between programming ecosystems.
How to Read the Book
You do not necessarily need to read all 97 essays in order.
Because the chapters are short and relatively independent, the book works well as a reference.
For example, if you are currently struggling with testing, you can focus on the testing-related essays.
If you're working on a large legacy project, read the chapters about refactoring, code quality, version control, and maintenance.
If you're beginning your career, start with:
Continuous Learning
Read Code
The Professional Programmer
Code Reviews
Testing
Simplicity
This makes the book useful both as a linear read and as a professional reference.
Key Lessons for Modern Programmers
Although the book was published in 2010, many of its principles remain relevant because they concern fundamental software-engineering practices rather than temporary technologies.
Here are some of the most valuable lessons:
Write Less, Better Code
More code creates more maintenance.
Prefer Simplicity
Simple systems are generally easier to understand and change.
Test Behavior
Tests should verify what the software is supposed to accomplish.
Read Existing Code
Professional development involves much more reading than beginners expect.
Keep Learning
Programming is a constantly evolving profession.
Automate Repetitive Work
Computers are excellent at repetitive tasks.
Use Version Control
Track changes and make collaboration safer.
Think About Users
Developers are not automatically representative of users.
Choose Appropriate Abstractions
Abstraction should reduce complexity, not hide it behind unnecessary layers.
Treat Code as a Long-Term Asset
The code you write today may need to be maintained by someone else years later.
Is the Book Still Relevant?
Yes, particularly at the level of software-engineering principles.
The book does not teach modern frameworks such as React, FastAPI, PyTorch, Kubernetes, or today's generative-AI tooling. Those technologies have changed significantly since the book's publication.
But concepts such as:
Testing
Simplicity
Code review
Version control
Refactoring
Automation
Domain understanding
Good APIs
Appropriate algorithms
Continuous learning
remain fundamental.
The O'Reilly catalog still presents the book as a beginner-level programming title, and its table of contents continues to emphasize these language-independent engineering principles.
Hard Copy: 97 Things Every Programmer Should Know: Collective Wisdom from the Experts
Kindle: 97 Things Every Programmer Should Know: Collective Wisdom from the Experts
Download the PDF for free:
https://github.com/Babunashvili/Books-To-Read-Before-You-Die/blob/master/Ebooks/97%20Things%20Every%20Programmer%20Should%20Know%20-%20%5BHenney%5D.pdf
Final Verdict
97 Things Every Programmer Should Know is not a book about learning Python, Java, C++, JavaScript, or any other specific programming language.
It is a book about becoming a better software developer.
Its greatest strength is its variety. Ninety-seven short contributions provide different perspectives on programming, software design, testing, debugging, collaboration, tools, maintenance, and professional growth. The contributors include experienced practitioners such as Michael Feathers, Pete Goodliffe, Diomidis Spinellis, Cay Horstmann, and Verity Stob.
Some chapters may feel obvious to experienced developers. Others may challenge assumptions or provide a new way of thinking about familiar problems. That variety is part of the book's appeal.
The most important takeaway is that programming is not simply about making code run.
.png)
Posts
