Reviews

97 Things Every Programmer Should Know by Kevlin Henney

rodhilton's review against another edition

Go to review page

2.0

"97 Livejournal Posts: Collective Suggestions from 20 Experts You've Heard Of And 77 Random People"

This is a book with 97 tips for programmers, each tip takes up two pages or less, written by different programmers (a few get more than one entry). Here's the problem: 2 pages isn't enough to say anything useful about anything. And taking 97 useless writings and concatenating them together doesn't create a useful one - the size limit of each entry prevents anything from being particularly valuable.

Sure, there are some gems occasionally, but it's mostly the same old stuff everyone knows (write unit tests, learn commandline tools, write good comments, write no comments, refactor, DRY, SRP, etc) and a handful of random crap (learn a foreign language). Hilariously, there are occasional serious computer scientists thrown into the mix - one post goes into a lot of detail about how floating point rounding errors happen, including formulas and mathematics, and his tip is sandwiched between a tip on encapsulating behavior with state and one on contributing to open source (as a side note, I am getting kind of tired of the attitude that open source projects are a great dumping ground for practicing your programming skills, rather than real projects worthy of the same kind of care and consideration as your day job).

"Install Me" wins the award for being the whiniest, most annoying post in the entire pack, it should be mentioned specifically.

In any case, most of these posts are a lot of "trust me" or "based on my experience" - no claims have any real evidence, and no tutorials or suggestions contain useful examples - how could they, with only two pages to work with? Every one of these suggestions should be the central thesis of its own book that goes into greater depth, and collecting 97 book descriptions together does not make a new book.

Here's a good rule of thumb: if you are a writer contributing to a book, and someone asked you to do a 90-minute presentation on your material, could you do it? How about a 60 minute presentation? 30? A 5-minute lightning talk, at least? If your entire contribution can be covered in an elevator ride, it's not worthy of a book.

There are probably 10-15 pages worth of good stuff in here, but even that isn't really very good. Not recommended.

jclermont's review against another edition

Go to review page

3.0

If you're a programmer, you should definitely read this book through at least once. I'd say about 25% of the book was not directly relevant to me, 50% was something I was already quite familiar with, but that remaining 25% was excellent material that made me think in new ways. Each essay is only 2 pages, so you won't go in-depth on any topic, but it will hopefully spark your desire to learn more.

One critique of the book is how it's organized. It appears that the 97 items are simply listed alphabetically by title. Grouping these into logical subjects would have made more sense I think.

tbueno's review against another edition

Go to review page

4.0

This is a nice book, with short (2-3 pages long) essays and opinions about software development. As one would expect from books that group multiple authors, the quality of the ideas varies a lot through the book. But i think the overall quality is high.

It is also important to keep in mind that this book is more than 12 years old already, so some idea might not have aged well.

Still, it is a nice book to read for short minutes while you wait for your build to pass, since each chapter is like 2-3 minutes long. ;)

tamouse's review against another edition

Go to review page

3.0

I tried to like this book. And maybe it could be really good for a newer person, but I've known all these things for a really long time. Most of them get burned into you after your third huge project.

Even so, I would really recommend this book to people starting out -- not that they'll understand at all why they need to know any of these things, but that when they have forgotten them, been bitten by them, they can recognise that these things are known, they aren't the first person to encounter them, and that there is probably a body of knowledge they can explore.

weebit's review against another edition

Go to review page

informative fast-paced

4.25

computerwhiz's review against another edition

Go to review page

4.0

It's a decent book, although it's probably geared more towards beginners. Most of the advice and concepts presented in the book are pretty common knowledge for most programmers with experience, so there's nothing groundbreaking. Given how brief each "chapter" is (which is the point of the book), this book serves mostly as a place to start when deciding what you want to explore in more depth, at least in my opinion.

fredtyre's review against another edition

Go to review page

5.0

Great book. I really enjoy the stories that go along with the bit of wisdom mentioned. Although I agree that all programmers should know these things, no one environment can fit into the mold that would allow for all scenarios in this book to work out positively. I work for a small enough team that we don't have a QA department, for instance. Still, the book is a fun read and has some good tidbits to remember.

mdzhang's review against another edition

Go to review page

3.0

I found some tips a bit dated and others a bit enterprise-y (esp as it pertained to the division of roles between different types of developers), but overall worth the read. For those who have already read a couple of programming best practices books or been programming professionally for a couple years with a critical eye, you are unlikely to discover anything very new.

I did find a number of points not worth reading or unnecessarily verbose and easily boiled down into a bullet point or two.

joergr's review against another edition

Go to review page

3.0

97 very short pieces all containing little insights into what makes one a better programmer, written by a field of experienced programmers - mostly white dudes.
It's a short read, and definitely worth going through. There is a lot of good insight. I would say 60% of the pieces contain a valuable message - do testing. be careful of this usual pattern in testing because here's an anecdote where it failed. don't use this pattern. The other 40% I would say suffer from programmer's arrogance a bit too much and are very debatable. About 5-10 pieces actually are great and make sifting through this book worth it.
But again, too many white male voices. I'm certain that diverse voices define a broader insight. Especially since pieces approaching programming as a people problem from a bird's eye view are rare in this book, I'm sure that replacing these 40% debatable pieces with more the voices of women, people of color or women of color would make this a 5 star book.
As it is, I recommend it for every programmer, but I also can't get excited about it.

rsilvery's review against another edition

Go to review page

2.0

Seemed like mostly common sense stuff. The only real thing I learned was the concept of "technical debt".