Book Review: 97 Things Every Programmer Should Know

review

Right now it feels like there are 97,000 things I need to know, so I thought it was time to pick up 97 Things Every Programmer Should Know (Edited by Kevlin Henney) and see if what it held could help me along my path.

A quick flick through the list of contributors threw up some names that I already knew, like:

  • Russel Winder who is an author of a number of books, but in particular of Developing C++ Software, which I remember buying as a student.
  • Scott Meyers of Effective C++ fame - another book I owned and admired.
  • Robert Martin, the founder and president of Object Mentor, Inc, whom I have been coming across a lot lately, especially when reading about Agile processes and,
  • Cay Horstmann. Now his name drove me mad because it just sounded so familiar. It turns out it was: he is the guy that wrote Violet, a free UML editor written in Java which I used to use years ago (and was really impressed with). Check it out - you won’t be disappointed, especially if price is a motivator.

However, I am sure that if I were better read, many of the others would be just as familiar. Anyway, onto the book.

There are about 229 pages but to be honest, probably only about 194 (97x2) of them are actual contributions since most seem to span a couple of pages, and those pages aren’t fully filled. That’s OK though because it makes this an easy read to pick up and put down as you like. In my case, I skim read all of the book apart from the contributions that were applicable to me or meant something poignant, so bear that in mind as you read this; I didn’t thoroughly read everything!

My first impressions were that it was going to be a dry book because some of the topics didn’t resonate with me, some of the writing was really formal and parts quite onerous to read. To be fair, many of the people that submitted items to this book probably don’t have English as their first language so it’s worth giving some consideration in respect of that. I am glad I persevered though because there are some gems in here. Perhaps not brand new insights for everyone, but at least useful reminders that don’t hurt to be repeated every now and then. It’s some of those that I want to share next.

  • Kevlin Henney (the Editor, no less!) on p34 wrote about the need to only comment on those things that the code doesn’t already say. In effect, don’t waste time stating the obvious, but instead, wrote comments of value. He used a phrase which I like called noisy comments to describe those that just add clutter and are meaningless.
  • Clint Shank (p36) wrote about the need to be continuously learning (to remain useful and competitive) and goes into some depth explaining ways in which you can do that. I heartily agree!
  • On p50, Rod Begbie talks about a humorous anecdote and describes the dangers of being complacent about using less than polite test data. The reasoning is that no-one will ever see them, until they do, of course!
  • Ignoring errors is the topic on p52 with Pete Goodliffe where he talks about the need to be vigilant with our code, not ignoring return codes etc. As he says, ignore them and you “run great risks.”
  • Anders Noras spends some time on p54 on the need to understand more than the language we use, but also the culture. He really underlies his point well by describing how his understanding of other languages have contributed to his effectiveness with others. For example: knowing how to use delegates effectively in C# by using Ruby.
  • Richard Monson-Haefel basically says: don’t let any boring projects you do at work, hinder your ambitions - get involved in open source. He then goes on to expound the various benefits of this, much like Scott Hanselman often does.
  • The last ones I want to write about are by “Uncle Bob” (Robert Martin) The one on p134 was about being professional which really amounts to, in my words, doing the right thing and taking responsibility for your work. The other was on p16 and named the Boy Scout Rule. I really liked this one too because it is all about leaving the world a better place than you found it. In other words, for example, when checking in someone else’s module, perhaps improve it a little by choosing better variable names, or adding a comment here or there. I would say that of all of these, it is that last one which I think could genuinely make a huge impact in an organisation.

Overall then, how do I feel about the book? There are some brilliant entries within it but it does feel that you have to brush some soil away to get to the really good stuff. Definitely worth a read but perhaps borrow it from the library before buying to ensure it’s your kind of thing?

Hi! Did you find this useful or interesting? I have an email list coming soon, but in the meantime, if you ready anything you fancy chatting about, I would love to hear from you. You can contact me here or at stephen ‘at’ logicalmoon.com