I swear I had this post half written for a month before Karl Seguin’s almost-too-perfect post on the subject came across my reader yesterday. But I waited specifically for today for two reasons. The first is that you’ve already read your share of joke posts so I’ll be allowed some latitude. The second will be clear starting…NOW!
Exactly one year ago today, Brownfield Application Development in .NET was released. I don’t think the date was accidental but I can’t be sure. For my part, I’ll leave Manning to wonder the same thing about the publish date of this post.
Karl had more foresight than I did when he said:
I know that the day after I’d agree to write a book, I’d regret it. Writing is something I can only do when I don’t have to and when there’s no expectation of me. Once you agree to get paid you not only have a responsibility to your publisher, but also to the people who are going to spend their money. I know, beyond a shadow of a doubt, that writing and I couldn’t survive that sort of pressure.
There are half a dozen secondary reasons I took on the project. Yes, I thought the book needed to be written and yes, I thought it would help my career (though to my credit, I did realize the stupidity of that reason even before I signed the contract; more on that later). Yes, I thought it would help people, etc, etc, and so on and so forth.
The primary reason is the same one that I use to pick contracts: I thought it’d be fun. I love writing (or at least, I love writing the way I do; more on that later). That should be apparent to anyone whose read any posts here or on our defunct family rag (credit where it’s due, my brother is as much a creative force behind that one as I am, if not more so). The idea of essentially writing thirteen chapter-length blog posts held a certain appeal, especially to someone who has about as much foresight as a sixteen-month-old baby who hasn’t quite grasped the concept of gravity as he teeters on the edge of a dock (and hoo boy, remind me to tell you how I came by that analogy; preferably out of earshot of the missus).
Before I continue, I’ll be omitting all “in my opinion”s or “I think that”s from here on in but they should be implicit. If you wrote a book and had a dandy time, then you are proof that it can be done. That said, I deny your existence.
Writing a technical book is a horrendous, horrendous experience. It all but beat the love of writing out of me and did serious damage to my love of reading. A good chunk of it is exactly as Karl describes: the pressure of the responsibility. I’ve said this before but when you have deadlines looming (or, more often, long passed), it hangs over your head. You feel bad when you’re writing because you should be spending time with your family and you feel bad when you’re with your family because you should be writing.
Writing a book is nothing like writing a blog post, though it was suggested by at least one reviewer that it should be. I don’t mind carrying a casual tone on this here blog thingy talking about roadkill diners, and my love of plaid, and sister-wives and the like but it was nigh impossible to make that work for an entire chapter, let alone the entire book. So we reverted to a more traditional, though still somewhat conversational tone. It always bugged me but I had more pressing things to worry about. Like making sure the content was good.
My impression is that our experience was atypical. Talking with others in similar situations, they didn’t have the same complaints we did, even at the same publisher. That said, it all happened and even if it was all just a series of unfortunate events, these are things you normally wouldn’t have to deal with if, like Karl, you didn’t charge for your book.
So for all you budding, young technical authors out there, my advice based on personal experience is the same as Karl’s: Do not charge for your book. Instead, write some lengthy blog posts around a central theme and compile them into a free ebook. Or start a wiki.
There were two occasions where we considered not bothering with the contract and the publisher and just releasing the book as a wiki. I regret not giving it more serious thought because in retrospect, it would have been a better avenue to take for several reasons, not including avoiding all the hassle we went through:
- It becomes a living document
- No deadlines
- Others can contribute
- Arguably, would have been better received (and possibly more widely distributed) by the industry
- And if you are more materially inclined, it’s arguably better for you financially.
To explain that last point: My feeling is that if you release a high quality book/wiki, it will catch the attention of the industry/community. And it’s very likely you could get some interesting work out of that more so than you would because you published a book. And based on my experience, all it takes is a single three- to four-week contract to match or beat the money you’d get from royalties.
There were a few reasons I felt we could benefit from going through a publisher. First, if I did it myself, I highly doubt the book would have been finished to this day. Without the threat of a deadline, it just wouldn’t get done. Second, we have experienced people looking at, reviewing, commenting on the book. They’ll have suggestions on layout, on wording, on general gestalt of how books should look and how they should flow. And we did get a lot of good information on exactly this area. So much so that I recognize this blog post should have at least two images to break up the text.
But it’s my blog and I’ll do what I want on it.
Kyle the Cathartic