Thoughts On Writing A Book

As a postmortem for the book, I thought I’d highlight some useful things I learned.

How did this get started? An editor at Apress contacted me (via blog) letting me know they were seeking an author to write a book on Zune game development. The content on my blog was useful and advanced enough to show up pretty high on Google Live Search Kumo. Key learning: Put good stuff out on the web and advertise it, and people will notice.

Benefits. The first thing that came into my head was all the benefits I’d get. Some of them I didn’t realize until recently.

• Dollar dollar bill, yall . I’ve been published before, but it was only one chapter and I got paid by the page. Which meant lots and lots of delicious screenshots. In this case, we agreed on a scope of 150-250 pages (which inflated to about 390). I got a fixed advance payment (broken into 3 parts over the course of the book’s development) and will get a percentage of the sales in the form of royalties.

• Instant subject matter expert. Being able to say “I wrote the book on Blah” is a nice way to bring credibility to your repertoire. The downside of this is that even after writing a book, there is still an insane amount of learning to pursue. Nonetheless, spending the time to dive deep into every corner of a technical topic makes you a de facto expert in the field (look at Jim Wooley and his book on LINQ).

• Instant resumé eye-catcher. Most folks don’t have a PUBLICATIONS section in their resume.

• Community recognition. If you get involved and market your book, you can meet some great people who could open up new pathways for your career.

• Great for the mind. If you find it difficult to articulate complex technical concepts, writing a book is a great way to force you to organize such thoughts in a way that is useful for teaching and explaining.

• Best-in-class absorbency and a proven male enhancement formula. I haven’t figured this one out yet but I hear you are supposed to add it to anything you advertise.

  Key learning: Money is nice, but it goes away. Reputation is forever.

Challenges. I hesitate to use the word drawback, downside, con, or any synonym of these because writing a book is a very positive endeavor. To put it plainly, it’s not all sunshine and roses, especially when you are writing about technology.

• Insane time commitment. This is particularly bad if you are a perfectionist like me. From September until February I spent the hours of 10pm – 4am writing text and code, perfecting programs, reviewing technical & copy reviews, making changes, etc. And this was pretty much a daily routine. Key learning: You will want to write more than you want. Try to stick to original goals. Also, go outside from time to time.
• You don’t know as much as you think. Writing a book on a topic is a great way to make you realize you’re not an expert. But when you are done, relatively speaking, you know a heck of a lot. I had a technical review that came back with comments like “This is the wrong way to do X. If I saw this in a book at the store, I’d put it back on the shelf.” Ouch! Things like that make you better technically and help the book be the best it can be.
• Code and prose do not mix well. Writing a paper is hard. Writing code is hard. Imagine what it’s like writing a very long paper and writing 25-some-odd sample programs, and getting them to work together and complement each other.
• Keeping to a schedule. Apress assigns project managers per book, which helped me stay on track. It also meant I had to work harder some weeks to get a chapter out the door.
• Formatting. Every publisher has their own house style, and there are little rules you don’t learn before copy-edit that put a lot of strain on the copy editor (e.g. you cannot have numbered lists within an exercise). Writing is tough and adhering to the format is another thing you have to manage in parallel. It’s harder than it sounds.
• Chasing releases. I wrote this book across three different incarnations of XNA 3.0 (CTP, Beta, Release). At the end I had to go back and change a couple of things. It’s hard to write about a quickly moving target, so you have to place some kind of marker in your chapters to remind yourself to go back later and write based on the current release.
• Facing obsolescence. Software gets upgraded; it’s a fact of life. At some point, nobody will use XNA 3.0 and unpurchased copies of my book will lay orphaned in a warehouse talking about the good old days. Until then, here’s hoping that folks find the book to be a useful guide, temporal as it may be. Key learning: Software becomes outdated quickly, like moon boots.
• Worrying about demand. Games for the Zune is kind of a niche topic. Lots of folks are making iPhone apps, because there are stories out there of people making insane money off of the app store. Demand for the book is, however, not the author’s concern unless you are expecting to live off royalties. Apress identified the need for a book in this space, found an author and put the book out. Key learning: It’s out of your hands. Don’t worry about it – you wrote a book!

Right now, I am very relieved to be done – it was an enormous undertaking, bigger than I thought. I expect to see my first review copy next week sometime, and it will be on shelves Mar 23. Then, I will have to go to the bookstore and see if anyone’s flipping through it, and then have an awkward moment where I ask myself whether or not to say I wrote it, and then walk away in an equally awkward manner.