Books vs. blogs: the value of technical books and ideas to improve them
[Disclosure: I am writing a technical book]
Everybody Googles. There, I said it.
There are too many frameworks, and too many technologies for it to be a responsible decision to attempt to memorize them all. We refer to the web constantly when learning new technologies or pushing through insipid bugs. I’d even go so far to say that this is a desirable characteristic of a developer: someone who knows where to get information when they don’t know the answer, or when the path to a solution is vague. Of course, you need filters to safely learn from the web, or you might pick up bad habits, erroneous code, or unknowingly breach licenses in your pursuit of knowledge (or laziness). Risks like these lead some to embrace technical books. Some say technical books are dead or dying.
What is a technical book?
A technical book is not:
- a fundamental work of guidance, like Code Complete or Framework Design Guidelines
- a patterns and practices collection like Head First Design Patterns that is fairly technology agnostic
A technical book is:
- an API reference that is specific to a particular technology or framework, and even more so if it is versioned
- a patterns and practices collection that is specific to one or many implementations
Don’t write a technical book
When I was negotiating a book contract with my favorite publisher earlier this year, many people told me not to write a book, so much so that I decided not to write it. There are quite a few blogs on the subject. Here’s a reading list:
- Do Not Buy This Book (Coding Horror)
- Programming Book Profits (John Resig)
- Hard Work, No Pay: What’s the Point? (Charles Petzold)
I don’t believe that these posts about the perils of writing a technical book are meant to protect the status quo for a small elite of successful authors. I do believe that these are real warnings from impassioned people who wanted to contribute to the community in book form (and make money) and emerged battered, or at least wise, by the experience. It seems the story of writing a book is a sad affair.
Write a technical book
There can be physical differences, of course, between books and blogs. The differences might provide ancillary advantages like portability or aesthetics, but those aren’t the advantages of books over blogs that are going to win anyone over. They’re built-in, and if they were real advantages, then nobody would be worried. But we have e-books. And audiobooks. And podcasts. And Kindle.
The value of a technical book, and the advantage it has over blogs, and the advantage it has that can help it continue to thrive despite the alternatives is, to me, identical to the value of any book on any shelf:
I buy a technical book for the story.
A story is complete (it has a beginning, a middle, and an end). A story treats the material like a complete whole, and it has context. While a blog offers schizophrenic, just-in-time information to help me tell my own story somewhere else, a book is, or should be, a story about me, using the technology, encountering challenges, overcoming them, and emerging the hero. That is, after all, the story I and every developer I know faces on a daily basis. Hero mileage may vary. [Update] I don’t mean to say that a technical book should contain an actual narrative, only that it provide context and that the source material paints a complete picture (for example, a reference application).
Bill Wagner’s Effective C# (and More Effective C# which is in early access), is the prototypical example of a great technical book. The story of this book is the one about how you decided to really dig in to your career as a developer and master C# by applying sound practices that are grounded in how the C# compiler actually generates the MSIL bytecode that becomes your application. I love this story, and turn to it often to remind myself that bytecode is the linchpin of quality programming. It never lies.
Ideas for improving technical books
- Tell a story
A good story is a reference application: some semi-real world application of the story that is believable. It looks and feels and like an application I could be asked to write tomorrow. Even better, involve me in the story by providing some reusable hooks into the design that let me actually use the source code in my application. Provide a Visual Studio template that sets up any practices or patterns you’re recommending in the book. - Make my technical book a subscription
I know that technology and approaches change often, so why doesn’t my technical book? If the book is titled along the lines of "Building Flexible Service Layers with WCF", I know that the book is an API reference, but I don’t know what version of WCF, or whether today it is useful to use yesterday’s pattern. This is especially true for emerging platforms like Silverlight (anyone still own their Silverlight 1.0 books?) A subscription-based technical book is an on-going investment in the story of accomplishing the book title’s objective. If the story changes, blogs change overnight, but the only part that changes on a static book is the price tag. - Involve multiple authors on the same book
A consequence of the improvement above is that an author will likely move on; just like projects, I don’t imagine anyone would want to write an objective-based subscription book for years. Less politely, as developers advance their careers they take leadership roles, become less involved in the intricacies of the current technology (this is often necessary), become more involved with their families (this is a good thing) and may broaden their perspective. This is not always the case, but a technical book, especially one living through multiple versions like the previous example, would benefit from fresh eyes, ears, and laser focus. - Version the book (code and pages)
Technical books are usually about code, and code is versioned. Let me visit your web site (or my book subscription) today, and download an on-demand generated PDF, or order a fairly priced print-on-demand solution that lets me get today’s version today. If I want to "Build Flexible Service Layers with WCF", presuming that WCF lasts several versions, I would love to order up this objective in the version my project uses. If I have multiple projects that use different versions, I know my subscription covers PDF access to all of them. Errata is inevitable, but it is manageable if my subscription covers online code access to the book’s source code repository. You could even let me submit a patch.
Bloggers and technical book authors can live in harmony knowing they both fill a need. A lot of the times they are the same person, but they do not have to be. Writing a book requires a sense of style and rigor that you simply don’t need to write a successful technical blog (though it helps). Here is a good blog post on one author’s experience.
I’m on your technical blog because I am writing a story, the story of my work day, and I’ve got writer’s block. I need just-in-time information that’s relevant and current. I don’t want to skim through your archives, and it’s quite possible that I won’t be back (unless I keep landing on your blog during my research, in which case you get tossed into my feed reader).
Technical books aren’t dead, but good ones are harder to find. A few changes to how technical books are read and shared will make them more accessible and may even encourage more sales from developers hungry for good stories.
