Book Review: 97 Things Every Programmer Should Know

Review

Title: 97 Things Every Programmer Should Know

Author(s): Kevlin Henney & others

As you might guess, this book contains 97 tips and advices for programmers (nowadays "developers"). Each tip is 1.5 to 2 pages long, and the topics are very varied: From design patterns and good coding practices to testing, refactoring, debugging, Continuous Integration, compilation/build & deployment... but also other areas like estimations or collaboration (code reviews, pair programming, etcetera).

It's from 2010 so starting to feel outdated at some places, but in general the advices are still relevant as of today (mostly why I kept reading it until the end).

Can be read quickly, and doesn't contains much code. Also, with brief texts comes brief descriptions, so if something interests you, probably you will have to dig deeper on your own.

Not bad, not a revelation, still a good reminder of (mostly) good practices.

Notes

Miscellaneous, unsorted notes (far from all of the book contents, though)

• leveraging technical debt
• Referential Transparency
• Understand your users (false consensus effect)
• Many incremental changes instead of a huge one
• Check and add tests
• New tech is not enough on itself to justify a refactor
• Sharing code (components, libraries) creates dependencies, take that into account
• Boy Scout Rule (leave the code better than you found it)
• Concentrate on building business-domain code as much as possible (today evolved to "build vs buy")
• Simplicity wins
• Explicit domain concepts
• Good encapsulation. It's all about narrow interfaces
• Code layout: easy to scan, standardized, expressive, compact
• Do code reviews
• Reason about: Preconditions and postconditions for functions, invariant for loops, immutable objects whenever relevant
• Nested sections -> Nested functions
• Short, single task focused functions, with few parameters
• Code comments: only relevant ones. "Comments as code": Either they add value (complement code) or are waste to remove/rewrite
• APIs:
  • Difficult to get right the first time, more difficult to change later
  • Good abstraction
  • Symmetry and consistency
  • Expressive
  • Convenient for the caller
  • Write unit tests for code that uses the API -> surfaces hurdles
• Don't ignore/silence errors, fix them
• Learn a language, but also understand its culture
• Interfaces exist for the convenience of their users, not their implementers
• Domain-specific types over primitive types (e.g. VelocityInKnots)
• Prevent errors by helping/aiding the user. Massage input, offer hints, cues, defaults...
• Write code as if you had to support it for the rest of your life
• Write tests for the people trying to understand your code