Brownfield Application Development, one year later
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.
We didn’t have a good experience with our publishers at all. There were communication issues almost from the start, not least of which because we switched development editors partway through.
We finished the first draft in December 2008, almost a year after we started and five or six months after we said we would. We both breathed a sigh of relief thinking we were in the home stretch, especially when we didn’t hear from anyone for several weeks. Alas, we weren’t even at the halfway point in our journey. There were reviews and rewrites to be done. One of the major corrections was to convert all our Canadian spellings to US ones. Which wouldn’t have been too bad except that we confirmed with at least two people early on (one of whom, admittedly, was our long-departed development editor) that we could use Canadian spellings. When told we’d have to change it, we did what anyone in our position would do: threw a hissy fit on Twitter that, in hindsight, was probably better-suited to a different venue. Like Facebook.
It wasn’t all bad. Our editor, Mike Stephens, is some kind of miracle negotiator for being able to always find some sensible middle ground during times of tension. And I think I fell in love with our proofreader, Katie Tennant, for a little while there at the end. As for everyone else, I don’t begrudge them anything. They’re all lovely people to chat with. I just feel like we fell through the cracks one too many times. Maybe the topic wasn’t sexy enough, maybe we had differing expectations. Maybe there were internal issues we weren’t privy too.
So here we are a year later with still a couple of unresolved items which I’ve avoided bringing up. First is the fact that we haven’t had our “wrap up” conversation with them to discuss what went well and what didn’t. Tried once but the fellow we were to meet with didn’t show. After that, I said we weren’t meeting with them until I had received the 25 complimentary copies of the book I was entitled to, which I had been trying to extract for them for some weeks by that time. Unfortunately, the package showed up the following week. Fortunately, it contained only 15 copies so technically, the demand remains unmet.
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.
Hillbilly out!
Kyle the Cathartic