Book Review -- 97 Things Every Programmer Should Know
November 06, 2012
Earlier today (while waiting for software to install on a client's server) I finished reading "97 Things Every Programmer Should Know" (Editing by Kevlin Henney). It's a collection of different bits of wisdom, contributed from a variety of different authors.
Each "chapter" is 2 pages long, which makes the book easy to pick up and put down, reading the 97 "things" a little at a time while waiting for software to install, or other "I have 5 free minutes" kind of situations (which isn't really something I personally see in a lot of techie books, not to this degree anyway).
For the most part, the book is pretty language-independent. The advice isn't syntax specific to, say, C++ or ColdFusion (both languages that I love using); it's mores high-level information that can be applied to any project. Topics range from improvements for testing (both ideas on how to automate tests as well as how to better handle communication between developers and QA engineers) to tips on refactoring code, to thoughts on what to put in source control (everything -- yes, everything). There are a few small sections in the book that use actual lines of code or references features in a specific language (C# comes up in 2 or 3 of them), but these are all done in pretty widely accepted languages such as Java or C++, and the code samples are incredibly small (less than 5 lines of code each time), so the concepts can be pretty easily understood, even if you've never written a line of C++ before in your life (seriously).
There are also a handful of chapters that discuss different benefits of command-line tools, learning Unix toolsets, etc. In those cases, one could argue these are language-specific (or at least platform specific) but the book also includes references to Cygwin, making that a bit of a moot point (and providing yet another piece of advice, if you weren't yet familiar with Cygwin).
Some of my personal favorite bits of advice found in the book...
The whole book is roughly 200 pages, including short bios on each contributing author (which in itself was useful, as several bios mentioned other books and podcasts that were unfamiliar to me -- like Software Engineering Radio, for example, and the book "Working Effectively With Legacy Code"). Not a huge time commitment at all, and definitely worth a quick read.
Because the book is so language-independent, it's got good reusability. Unlike say, my book on Classic ASP, this is one that I might find myself re-reading again in the future. :) Along those lines, it also reminded me of "Secrets of the Rock Star Programmers", which I'd also recommend checking out.
-nolan
Each "chapter" is 2 pages long, which makes the book easy to pick up and put down, reading the 97 "things" a little at a time while waiting for software to install, or other "I have 5 free minutes" kind of situations (which isn't really something I personally see in a lot of techie books, not to this degree anyway).
For the most part, the book is pretty language-independent. The advice isn't syntax specific to, say, C++ or ColdFusion (both languages that I love using); it's mores high-level information that can be applied to any project. Topics range from improvements for testing (both ideas on how to automate tests as well as how to better handle communication between developers and QA engineers) to tips on refactoring code, to thoughts on what to put in source control (everything -- yes, everything). There are a few small sections in the book that use actual lines of code or references features in a specific language (C# comes up in 2 or 3 of them), but these are all done in pretty widely accepted languages such as Java or C++, and the code samples are incredibly small (less than 5 lines of code each time), so the concepts can be pretty easily understood, even if you've never written a line of C++ before in your life (seriously).
There are also a handful of chapters that discuss different benefits of command-line tools, learning Unix toolsets, etc. In those cases, one could argue these are language-specific (or at least platform specific) but the book also includes references to Cygwin, making that a bit of a moot point (and providing yet another piece of advice, if you weren't yet familiar with Cygwin).
Some of my personal favorite bits of advice found in the book...
- Act With Prudence -- any explanation of "technical debt" that helps explain that concept to clients is worth reading!)
- Ask, "What Would the User Do? (You Are Not The User)
- Before You Refactor
- The Boy Scout Rule
- Code in the Language of the Domain (see my earlier post about the getMeridiem() function for a small semi-example of this)
- A Comment on Comments
- Continuous Learning
- Domain Specific Languages (this is becoming a huge thing for me -- I keep running into more and more problems for clients that DSLs really help to resolve, and very effectively at that!)
- Don't be Cute With Your Test Data (there's a semi-famous story from a video game company I used to work for that provides a great real world example of this...maybe I should blog it later...just for the record, it wasn't MY code or test data! *g*)
- Don't Ignore That Error
- Learn to Estimate
- The Longevity of Interim Solutions
- Pair Program and Feel the Flow
- Prefer Domain-Specific Types to Primitive Types
- Put the Mouse Down and Step Away From the Keyboard
The whole book is roughly 200 pages, including short bios on each contributing author (which in itself was useful, as several bios mentioned other books and podcasts that were unfamiliar to me -- like Software Engineering Radio, for example, and the book "Working Effectively With Legacy Code"). Not a huge time commitment at all, and definitely worth a quick read.
Because the book is so language-independent, it's got good reusability. Unlike say, my book on Classic ASP, this is one that I might find myself re-reading again in the future. :) Along those lines, it also reminded me of "Secrets of the Rock Star Programmers", which I'd also recommend checking out.
-nolan