I'm perhaps a little old school in my philosophy on learning new technical skills. There are millions of web resources out there to reference common development or design tasks. But the truth is, most of them (including this blog) don't provide the detail required to really understand what your doing. It's not a failure on the part of the blog post or article, it's not what they were designed to do.
On the flip side, there are so many books out there on any given topic, that it's difficult to weed through the ones that are written like a bunch of blog posts with page numbers and a binding (giving you no actual understanding or background on what you're doing).
I've purchased a good number of programming books over the years, and have started to identify some key aspects common to all of the good ones, so I thought I'd share:
- Explanation vs. source code. I've see both extremes – books with far too many code listings and books with almost none. On the one hand, code listings are a great complement to a deep explanation of a language syntax, pattern or construct, but they are no substitution. On the other hand, paragraph after paragraph of descriptive text without an example is almost useless.
As a rule, I look for books where the majority of source code listings are less than a page long. We're not trying to create small programs, we're trying to learn new concepts.
- The index. The table of contents is great for a first read, but after that, you'll be hitting that index. After perusing all of the books in my top 10, I found that they all had at least one index page for every 50 pages of text. However, I'm still usually a little disappointed by the index, even in the best books.
- The Price Tag. Obviously this is not a hard and fast rule, but typically the price of a technical book speaks volumes about it's value. After running through my little home library, I've noticed a pattern. For the most part, the books under $20 leaned a little bit more towards reference books – content I can easily find with a few Google searches, although perhaps not as organized.
The $35 and up range were typically "good reads". You can really tell the author has a deep background on the subject and spent a good deal of time thinking about how to present the material and explain the inner workings of the language (if we're talking about a programming book).
- Publication date. The may sound ridiculous, but I've that even with technical books – "oldies are goodies". Why? Because the information isn't solely reference material. The concepts are core, the code listings stand the test of time and the "soul" of the book is more about the "why it works" than the "what specific lines of code do I need".
This rule, of course, is quite the opposite for reference books, which should be as current as possible.
- Is it used in Academics? I didn't realize it at the time, but the books I complained about purchasing in college were some of the best books on the topic. Since unloading those books 15 years ago, I've found myself regretting it. Amazingly, they are still relevant, and totally worth the money (often in the $100 range).
One option is to peruse a college bookstore online and see what they're requiring for CS classes these days.
- References. Again, you're gonna think I'm nuts. But, going back through my top 10 books, I've found that few of them even had references to other works. Then it hit me, the more references, the more of a reference book it is! An author who can fill a book with original material, not citing a single source, truly knows the topic at hand, and often times had a hand in the topic (assisted in the development or improvement of a language, concept, or process).
- The Author. Lastly, and most importantly, the author's reputation.
- Have they written any other books? How are the reviews?
- Do they speak at conferences regularly?
- Is their website current and active?
- Have they been "doing this" for a long time?