Notes on

97 Things Every Programmer Should Know

by Kevlin Henney


  • Avoid technical debt. If you can't, at least pay it off as soon as possible.
  • Know functional programming principles. Applying them brings a higher degree of referential transparency. This means that your functions does as their names indicate, and no more. This means little to no side effects.
  • False consensus bias: we think people think like us. We label them as 'defective' if they don't.
  • Automating code standards
    • Make formatting a part of the build process.
    • Use static code analysis for unwanted antipatterns. Break the build if they are found.
    • Don't only measure test coverage - check the results. Break the build if the test coverage is too low.
  • Before you refactor, read the existing code. Understand it. Understand its faults and its merits. It's easy to think you can do better without doing so, but you may end up doing worse.
  • Be careful with throwing out code. It's already battle tested if it's in production. And it may contain fixes that you aren't aware of.
  • Many small changes are better than one massive change.

Liked this post? Join the newsletter.