Stop Searching and Read A Book

Disclaimers: I’ve written three technical books.

Background: Tim O’Reilly, via David Farber’s IP mailing list, pointed at Danny Sullivan’s posting that shed some much-needed light on the the arguments for regulating search. Sullivan’s object of satire was an op-ed piece suggesting that Google’s search algorithms be subject to scrutiny and therefore regulation. Marissa Mayer’s piece presenting Google’s view is on their public policy blog as well, neatly triangulating the issue. Kind of.

Here’s the issue: search is not about getting exactly one answer, or the best answer, or even a set of correct answers for some values of “correct”. Search turns data into information, giving some pieces of data priority over others and presenting those data in a user-friendly way. But there’s a difference between “information” and “value”. Search results only have value if they answer the question to your satisfaction. You, not Google, not Yahoo!, not Microsoft, and not the government, have to distinguish good results from junk. There’s nothing to regulate here – and yes, the results vary by platform and algorithm, and are colored by advertising sales. Suggesting government regulation implies that consumers aren’t smart enough to build their own value scales – something we do every time we are exposed to advertising in print, on radio or via television.

There’s a flip side to the search issue – we have a personal responsibility to quantify the value of search results, but we have an equal responsibility to better understand the context for our questions. Which brings me to search and the technical book market.

The technical book market is in the toilet and has been for a decade, since readers find it easier to search for the answer they believe they need rather than read a chapter of a technical book that explains the topic in detail. This outcome is the composition of several functions: search is faster than reading, search has no out of pocket cost compared to buying the book, and it provides instant gratification when that copy and pasted code solves your problem in a matter of minutes.

What if we aren’t asking the right questions, or don’t even know how to frame a better question? That’s the purpose of technical books – they tell a story, from the basic introduction to the deeper context. It’s what I learned twenty years ago in an invaluable lunch with Tim O’Reilly, and it’s still true. You can search for a code snippet, or you can read a book that explores other approaches to the problem and their technical context. We need to balance our ability to learn (and manage our own learning styles) with the surfeit of data clamoring for attention.