+++
title = "97 Things Every Programmer Should Know: Collective Wisdom from the Experts - Kevlin Henney"
date = 2020-03-22
updated = 2021-02-12

[taxonomies]
tags = ["books", "reviews", "it", "stars:3", "books:2020", "published:2010"]
+++

[GoodReads Summary](https://www.goodreads.com/book/show/7003902-97-things-every-programmer-should-know):
Tap into the wisdom of experts to learn what every programmer should know, no
matter what language you use. With the 97 short and extremely useful tips for
programmers in this book, you'll expand your skills by adopting new approaches
to old problems, learning appropriate best practices, and honing your craft
through sound advice.

<!-- more -->

{{ stars(stars=3) }}

It's kinda weird to read a book that your experience agrees with what it is
said: I have a collection of things I learnt in 30 years doing software
development, and a lot of things said in the book agree with it.

Now, because there are several authors, the writing style changes a lot: Some
are really dense and difficult to follow, some others are simple and fun to
read, and some feel really repetitive.

One of the downsides of the book is that they should get a more diverse group.
Sure, Uncle Bob is highly influential and has a lot of good tips, but giving
him 3 articles, when there are only 6 women and 2 black men in the list of
authors seems kinda a waste[^1].

Sure, for people starting in the development world, it's a good book, giving
some pointers on where to start, but for people who are in the area for some
time (and may already read some books/posts about the topics), it may feel a
bit like a waste of time.

## Highlights

>  Repetition in Process Calls for Automation 

>  Repetition in Logic Calls for Abstraction 

>  learn much faster by writing test code 

>  ANYONE WHO HAS WORKED IN SOFTWARE LONG ENOUGH has heard questions like this:
>  I’m getting exception XYZ. Do you know what the problem is? 

*Note*: I get that *a lot*!

>  As you work on a project, you will understand more of the problem domain
>  and, hopefully, find more effective ways of reaching the goal 

>  Hint: Write code because it adds value, not because it amuses you.) 

*Note*: Well, and what actually "adds value"? Does refactoring something adds
value, if the only thing it does is making it easier for *me* to understand?

>  That isn’t YAGNI. If you don’t need it right now, don’t write it right now.) 

>  The primary purpose of software estimation is not to predict a project’s
>  outcome; it is to determine whether a project’s targets are realistic enough
>  to allow the project to be controlled to meet them 

>  Try to learn from other people’s mistakes, so that your code won’t contain
>  the same ones.

*Note*: Work on new mistakes :)

>  IN ALL BUT THE SMALLEST DEVELOPMENT PROJECT, people work with people.

>  Compared to “hard” engineering, the software development world is at about
>  the same place the bridge builders were when the common strategy was to
>  build a bridge and then roll something heavy over it. If it stayed up, it
>  was a good bridge. If not, well, time to go back to the drawing board 

>  A bridge builder would never hear from his boss, “Don’t bother doing
>  structural analysis on that building—we have a tight deadline.

---

[^1]: No, I'm not saying that Uncle Bob isn't worth getting 3 spots, so maybe
  the list should have more than 97 points to let others also have a spot.