One of my pet peeves lately is software developers who believe that simply reading a book makes them an expert at some aspect of delivering working applications. You know the type of person that has just finished Agile Web Development with Rails is now selling themselves as a “Rails expert”. They aren’t. Let’s take a look at what you really have to do to “know” anything.

There is no way that our profession will be taken seriously when we have a segment of the people claiming they are the next David Heinemeier Hansson because they just got done with a book. These same people get on a project that has very real costs and deadlines and simply choke. They have a good idea of the big picture or are restricted to what the examples in the book show and that’s the extent of what they know. You can identify these people because they sound like they know what they’re talking about when sitting in front of management or kicking around concepts at lunch but somehow can’t perform the most basic of actions without either asking for help or taking an incredible amount of time to do it. Want a quick way to see if someone really knows anything about a subject? Ask them the “why wouldn’t you…” type questions about a subject. Most books cover the “why you need to do…” but don’t cover when you should break away from the recipe given in the book.

I often tell people that they (“they” is me too) don’t really know anything until they’ve had to work around the “asshole” of X. X can be a language, framework, library, application, etc. etc. “Asshole” is the nasty, ugly parts of X. Like real assholes no one wants to admit they have one but we all know that we all do. For example, you don’t know anything about Hibernate until you’ve had the “pleasure” of trying to map some seriously jacked up natural keys in a legacy schema. You can read all the Hibernate related books that you want but you are still a joke until you’ve worked around Hibernate’s ugly nasty parts.

In the interest of full disclosure I will admit that I read 2 to 3 development-related books a month. But unlike those people I’m ranting against here I see the information I get from a book as just a single starting point to help frame actual honest learning that will happen after I’m done with the book. For example, I have read 3 different books on Perl but do I know Perl? NO! I’m familiar with some of the concepts in the language and could probably understand a large amount of Perl scripts if I were to read them. Does Perl appear on my resume? No. Would I attempt to lead a Perl-based project? No. Why? Because I am still a Perl noob that only has a high level, weak understanding of the language. I haven’t seen Perl’s ugly bits.

So why do you read a book?