Good Technical Books

Toph asked me an interesting question today: What are my favorite computer programming books? I came up with a lot of the standard answers: SICP, The Smalltalk blue book, The C Programming Language (K&R), Dive Into Python, Essentials of Programming Languages. My goal now is to write a list of what makes a good programming book. My criteria are interest, longevity, and usefulness for learning -- reference books have been replaced by the web. I'm mostly doing this to organize my thoughts, and doubt it's news to anyone who actually writes technical books.

General writing stuff like knowing your readers, having a focus, and all that jazz are done to death -- I want to focus on books about computer progrmming, and what makes them good or bad as distinct from other books.

1. Thin books are better than thick ones. You can nearly always figure out what the best book on a given subject is just by its size. Buy the smallest one.
2. No screenshots or CDs allowed. Either of these things will date your book forever and make sure it seems like a dinosaur. If you must include graphics, take any widgets out. If you're thinking of distributing software on media with your book, don't. It's a disaster. Thankfully, book makers have gotten this second message, but many otherwise reasonable technical books are rife with screenshots. Exceptions to this are books about the interface, but nobody expects them to age well anyway.
3. Standalone sections. Your book should be divided into sections, and these sections should be individually comprehensible to somebody who mostly knows the material but is trying to refresh their memory. This doesn't mean you should repeat yourself or try to cover anything new, but I like to read an entire section without flipping through the book every five seconds.

4. Include exercises. Doing it is the only way I can really learn something. Solutions are completely unnecessary -- for software books, you can write your exercises so that it is obvious when it is correct. Examples of a good exercise:

   Write a recursive function to reverse a list.

   And a bad one:

   Define the types you would need to represent a car dealership.

   The first one is good because I know when I am done, and I can test. I also built something, which is fun. The second one is bad because I'm doing work that nobody will see, and I don't have anything at the end. Ideally your exercises will stand alone, but it's okay if they build on each other too.

5. Use code sparingly, unless it's the subject of your book. Small snippets will do. Nobody wants to see several consecutive pages of code in your book. An obvious exception to this is when your book is about large programs, like Paradigms of AI Programming by Norvig.

This is incomplete, but I'm trying to crystalize my thoughts here. I plan to use this blog to write thoughts like this in the future.

tech | link | 2006/May