97 Things Every Programmer Should Know: Collective Wisdom from the Experts (Free PDF)

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.