97 Things Every Programmer Should Know: Collective Wisdom from the Experts - Kevlin Henney

GoodReads Summary: 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.

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¹.

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.