| Home | Biography | Speaking | Articles | Books | Music |
For the last year (more or less), I’ve been writing and finishing two books, “CIL Programming: Under the Hood of .NET”, and “.NET Security”. It wasn’t the first time I was involved in the book writing process, so I knew what to expect. However, I can’t say that the process was smooth as silk, either. I ran into two incidents with other authors that just infuriated me.
The first problem was with the security book. I originally was going to write the book with another author. We started writing in the summer of 2001 with the intention of finishing in Dec. 2001. We each has 50% of the book, so I started slaving away at my chapters. However, as the due date drew near, it became pretty obvious that this guy hadn’t done much of anything. Sending e-mails that basically said, “Hey, you have to get done - what’s up?” didn’t help out the situation either. The only material he ever produced was a 7 page Word document where half of it were just notes on what he needed to do to finish the chapter.
The hard part is that I was also working on the CIL book, primarily because I fully expected him to hold up to his contractual obligation to finish the security book. If I had the time, I would’ve finished it on my own, but there was no way I could’ve finished the security book and complete the CIL book at the same time, and finish both by their respective deadlines. Fortunately, I was able to find three other people - Pete Stromquist, Tom Fischer, and Nathan Smith - to help me out in finishing the security book. I’m grateful for their contributions - they did a great job, especially under tight time constraints - but it made me pretty angry that I needed to scramble at the 11th hour because someone didn’t hold up their end of the bargain.
The ironic thing is, I had gone through this before. Early in 2001, I was doing a fair amount of work in eMbedded VB (version 3). Now, if you’ve ever used that tool, you know how painful it can be. I had to do a lot of work in eMbedded Visual C++ to create COM servers that would expose the functionality I needed but could not access in eVB. I wanted to write a book on PocketPC programming to share my knowledge, so I hooked up with two other guys who wanted to contribute material as well. Sure enough, when the deadline (April 2001) came up, I had turned in my 5 chapters, but there was no other material to be found from the other two. I tried to scramble and find other authors to pick up the slack, but it was too late. A new version of the eMbedded tools came out, plus the Compact .NET framework was already on the horizon. What really pissed me off about this situation is that I was really happy with my material, yet I knew it would never see the light of day. It was already obsolete. And updating it for the new version wasn’t an option as I was under obligations to get my CIL and security books done!
Needless to say, the last year has been a learning experience when it comes to the writing process. And while I encourage others to write about what they have learned, I’ve also found out that the expectations that some had about writing a book didn’t match up with the reality of the process. So I’d like to share a couple of tips and hints for the reader who’s thinking about writing the next technical masterpiece to help them make the experience as pain-free as possible.
First, here are the facts. Writing a technical book will not make you millions and millions of dollars. In fact, given the time that you’ll spend writing a book and the financial rewards that (usually) result from your endeavor, you’d probably make more if you worked overtime (assuming that you get paid for overtime). It’s not that you don’t make any money from a book, and I do know of a couple of authors who wrote books that sold thousands and thousands of copies (making their financial situations very nice). But don’t expect to retire after you write one book. Above anything else, you must have a passion and a love to write. If your primary motivation to write is to make money, I’d look at trying something else. One of the primary rewards from writing a book is getting respect from your peers. To me, it’s a building block that you can use throughout your career, especially if the book received good reviews. It’s not a building block for the foundation to your new 3-story 10,000 sq. ft. house.
If you’ve never written a book before, I’d strongly suggest writing an article or two for a magazine or an online technical site. Granted, you don’t get a lot of money writing articles (some web sites don’t pay anything for your contributions), but it exposes you to the work you need to do to write something that’s competent, cohesive, and clear. Plus, it’s easier to find a publisher that will print your article than it is to hook up with a book publishing company. Believe me, writing a 6-page article isn’t always a piece of cake, even if you know the material inside and out, so the experience is beneficial. You need to find out what it’s like to work with different publishers. All of them have different templates and schedules that they want you to use and follow to submit the article. Finally, it gets you some skills that you can use as a selling point when you finally try to market your idea (and yourself) to a book publisher. And if you can’t find anyone to publish it, set up a small web site, publish the article, and advertise it wherever you can on the Internet. You’ll probably get feedback from some of the readers, which will help you refine and polish your work.
This is a big one in my book. Talk to the companies. Find out what they offer in terms of royalties. Ask about what formats they’ll want you to use to submit your work. See if they’re looking at teaming you up with other authors, or if they’re going to make you work a ridiculous schedule (Quick illustration: The first book I ever wrote was done at a chapter per week pace. That’s why I’m bald.). Tell them about your idea and see if they’re interested in publishing it. I’ve found that book publishers vary on these and other issues (sometimes significantly), so make sure that you’re getting the best deal possible. Frankly, I think out of all the book publishers out there today, Apress simply rocks. They have their contract right on their web site, so you know exactly what to expect (I looked around, but I haven’t found this on the web sites of other publishers). Their royalties are great, the staff is excellent, and they’ll work with you to help you mold and solidify your idea. Whatever company you decide to go with, make sure you are comfortable with the contract. And make sure they don’t have any “right of first refusal” language in the contract either! Deep discount clauses that significantly reduce your royalties are another contract pitfall to watch out for.
I’m still working on this one myself - I’m finding out with each book that this is pretty important. If you have a good skeletal structure of how the book plays out, you’ll have a good foundation to build upon. But if you’re going in with the mindset of, “well, I know I want to talk about .NET controls later on in the book, but I’m not sure where … oh well, I’ll figure it out as I go along”, you’re sunk. Make sure the chapters flow from one to the next. The outline also helps you out in determining what you can knock off in a relatively short amount of time compared to those sections where you know you need to do some R&D first. I’ve found out that by having a good outline, I can then work on the material that is going to require more effort, and then I can end with the “easier” stuff (I’ve found out that you usually have more energy at the beginning of the project, so use it up on the harder material. Then you can end on material that isn’t as labor-intensive.) Since the outline gives me the structure, I know that I can write Chapter 6 first without having the material in the first five chapters fluctuate wildly. Granted, as in any project in life, the scope can change. But getting the outline together makes things easier in the long run, even if changes occur.
This is the hard one. Most of the authors I’ve talked to always speak of long nights at their computer, pounding away at the keyboard to get a chapter done. It’s rare for a technical author to do nothing but write technical books. Usually you’re working during the day at your “regular” job, which leaves the rest of the time for writing a book. You have to cut back on the leisure activities for awhile. I think this is what trips up new authors more than anything else. You have to sacrifice a lot to get the book done. If you don’t want to give up your XBox or your weekly frisbee golf league (or whatever it is that you do for entertainment), don’t write a book. If you’re in a relationship with someone, make sure your significant other supports your endeavor (and mention them in your book, unless you want to sleep outside for a month or two). They’re along for the ride as well. They won’t see you as much, and you’re going to get stressed out from time to time. Knowing that they’re OK with spending less time with you is extremely beneficial for your writing as well as your relationship.
This applies if you’re writing a book with other people, especially if you’re all new authors. Keep in contact with them. Ask how it’s going. Find out if they’re making progress. If you don’t, it’s too easy for someone to get overwhelmed by the commitment it takes and, at the same time, not say a word to anyone else. Granted, dumping an author and trying to find someone else isn’t always easy, but it’s better to do it right away than at the end of the process (trust me on this one).
There are other points I could make, but these are the essential ones that come to mind. Above all else, don’t sign that book contract unless you are fully committed to finishing it. And if you want to find out more about what goes on during the writing process, both Jeff Prosise and I kept book blogs of our recent books. You can read Jeff’s blog online here. Mine is in PDF format, which you can download here. I love writing books, but it’s not without its’ share of pitfalls and land mines. I hope that by sharing some of my experiences with you, it’ll help prepare you in case you ever decide to sit down at a computer and write a book.
Published: 07.31.2001