Sunday, June 24, 2007

Been Reading Crappy (Half)Books

I don't read a lot of books. At least under the definition of, you open it, flip pages over several days or weeks, get to the last one, read the last sentence, say "huh", and put it down. I mean, I don't finish a lot of books, at least nowhere near the number I start.

I *do* read a lot of half books - that is I only get half-way through. I have a feeling I'm rather hard on books - I expect a lot.

The problem I see is that there is simply an absolute deluge of books that should be articles. Simply said, books are about ideas. However (fixing the english of that last sentence), every book should be about multiple ideas.

So so so so many (half)books I read are only about one idea. They have a wispy chapter 1 introduction, chapter 2 introduces the idea (which sometimes is so simple it takes a paragraph), and then the rest of the book cites contrived/researched/induced examples about how that idea is so great.

That's fine and all. Some of those ideas are pretty luminary (i.e. Freakonomics comes to mind) but one single idea has to be pretty damn big to make a book. (Meta-note: the idea that books should be about multiple ideas and not just one idea is probably not a big enough idea to be a book, just an article, or maybe even a stinky little blog post).

I read a lot of technical books (not halves usually) and technical books are pretty hard to be stuck on one idea. Brian Goetz' Java Concurrency in Practice is a great example. If you're a Java techie, this is an incredible page turner. (Another amazingly great techie book is Warren's Hacker's Delight .)

I also read a lot of (half)books about business. I just read a (half)book called Selling Blue Elephants. The basic idea was to do market research using actual customer testing. Cool. Good idea. They even gave a spiffy acronym to try to add it to the world's business vocabulary (much like "tipping point" and "long tail" have done in the past few years).

But that was about it. The rest was case studies on how customer testing helped a bunch of products. Yip.

I also have been listening to Good to Great lately, a pretty heavily lauded book. I don't usually do books on CD but it was a gift. There was a lot of solid empirical research in it which was helpful but it seemed (much like Built to Last) to be fraught by survivorship bias. And I don't discount the strong research, but the results were somewhat expected (that's no ones fault, its just that everyone loves a plot twist).

The entire section devoted to how people in "great" companies tend to be stay friends is what really ended up ejecting the CD however. It almost seemd to imply was almost that if you were only in a "good" company, you'll never make any friends.

My expectations are probably too high. Business vs. technology is largely analogous to art vs. science - and its damn hard to write about art (as compared to science). Its just too subjective.

Becoming a great businessperson is analogous to becoming a great techie. It simply takes some level of innate talent that can't be replaced by hard work (and after you have that, then you still need a lot of hard work). After that however, the tech stuff is arguably easier to document.

Now I definitely might be too hard on books but how I figure it, I only get so many days on this planet (and this planet is the only one I know with books). I really can't afford to waste time on any book I find anything less than insanely great (Influence by Cialdini).
Ah well, onto the next - maybe I'll read some Call of Cthulhu. Or even better, "How to run a business like Cthulu would" - I bet there'd be more than one idea in there.

1 comment:

Mike Kaufman said...

Another reason my own book-reading has declined over the last few years is that "technical" books can't keep up with the pace of change anymore.

For anything product/technology-specific, books that appear in a timely manner are often based on no more knowledge than you could get from documentation and some quick experiments. Books that take longer to appear tend to miss the point where you most need them, and are quickly overtaken by events.

So the technical books I've been getting recently are limited to things like Doug Lea's "Concurrent Programming in Java", where there's expert insight into something non-trivial and that will stay relevant for a while. There aren't many such books that are also good enough, and we could soon reach the point where even these books age too quickly to be worthwhile.

I've also recently taken to re-reading old books on more fundamental stuff (e.g. algorithms, maths, concurrency, compilers...). It's amazing how much I thought I knew but had actually forgotten, and how often this provides a new insight into current stuff.

Pretty much everything else I now get "online".