This post is somewhat difficult to write. I’ve been involved in a few book revision projects over the past 10 years where I’ve picked up another author’s book and had to revise it for a new version of $widget or just to update it. When doing so, I notice that my writing approach is different than some authors. I can’t or won’t claim that my writing approach is better, in fact it may be worse, but it’s the approach that I use nonetheless.
When revising books I quickly become frustrated with what I view as oversimplification because it leads inevitably to incorrect information. Unfortunately, I can’t provide a real-world example because that would compromise the projects I’m working on. However, an anecdotal example is around DNS, where many authors don’t seem to understand the most basic things about DNS and therefore gloss over the details in such a way as to provide incorrect information for the reader.
I find myself completely gutting entire sections of books and having to rewrite them when the intention was to merely revise. A side-effect of this is that the section comes out shorter which some publishers don’t like; they like an increased page count. I like correct, accurate information, explained in the clearest manner possible. The funny thing is, (funny to me), I’ve done this to my own revisions too, where I’ve picked up something I wrote 5 years ago and think “what is this garbage?”.
Additionally, with books I revise or write from scratch, I tend to try to explain not only how something works but also why it works. Sometimes I’m successful at providing this explanation while at other times I fail miserably in both the how and the why. I feel that you, as the reader, are looking for more than just a tutorial on a subject; the web is full of tutorials. When you take the time and spend the money to read one of my books I hope to provide you with more insight than you would get from a tutorial or even a tutorial-based approach.
My approach to book writing should also serve as a warning to those readers who want a quick-and-dirty tutorial on a given subject. You won’t get that in my books. Sure, you’ll see the how, the tutorial, but you’ll hopefully also learn why you need to do it that way. This is how I learn, by seeing how to do something but then having it explained why it should be done that way. Like many people, I get paid to solve difficult problems on computers and with computer systems. My experience leads to being able to envision multiple solutions to any given problem. Therefore for me, it’s helpful to see a problem solved and then see why the problem was solved in that particular way.
Granted, this isn’t always the case, not every example has a multi-page explanation, but many do, and many sections within my books contain best practices learned from years and years of experience in the areas in which I write.
I’m involved in 4 book projects this year, at least two of which will be released this year while the remainder will come out in the first quarter of 2013. All told, this will likely account for somewhere just short of 2,000 pages (+/- 20%) of writing over the course of 8 months. The approach described in this post is being applied, as best I can, to each and every one of those 2,000 pages.