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