Tim O’Reilly states that the C# book market is up 78%, ASP.NET up 61% and Javascript 171% thanks to AJAX. SQL Server books have also boosted sales recently thanks to the release of Yukon. While this is undeniably good and indicates that development budgets are stretching a bit further these days, I wonder exactly how sales still compare to the heyday of mid 2000. For those unaware of it, this is when the dotCom bubble burst, book sales halved in three months and companies like Apress and Wrox were forced to either shelter under the cover of a new owner or go bust. It does feel like there is a new optimism to it all at the moment though. Unless you propose to write five or six books on using your iPod however, there’s still very little money in the writing business as an author or reviewer; it is still a matter of passion rather than money. That’s been true of writing across the board though.

What has been lacking recently is a way into tech book writing for those who are interested. Subject areas have been fixed for a while and there are only so many different ways to  However, the new influx of nascent technology - notably from Microsoft - and the introduction of CTP schemes does mean that there is a lot of scope for new authors to flex their literary muscles.

In looking back at my experiences though, a few words of warning to those entering the dark waters of writing.

  • Know your subject. It sounds obvious but writing a book is hard enough without you having to learn everything as you go along.
  • Know your audience. No-one knows as much about the subject you will write about as you. They will know more or know less. Define the level of knowledge for your target audience and stick to it. Don’t skip coverage on one subject because you think it’s too trivial or because you don't like it. This is a book - not an option piece.
  • Know what your editor will and won’t do for you. Time was that editors had the time to fix consistency of style across chapters, rewrite sections in better (American) English, test, debug and fix sample code and generally make authors seem even better than they were. This is not so much the case these days and it’s important to know what they will do for the book.
  • Know the format style. Writing MSDN documentation is infinitely different to writing a book which is inifitely different to writing a script. Research the format you want to write. Figure out why you like it and what you want to do with it. Let your editors know and put it in your initial proposal so they know what you want to achieve.
  • Know your language. Developers like things described unambiguously. It means that they can understand a concept, use it and move on. Putting a vague indecisive spin on things isn’t so great. It implies you don’t get something and that the developer will need to spend a couple of hours experimenting with code to determine a fact that they just bought your book to tell them.
  • Write. Edit. Leave. Reread. Edit. The first draft of a chapter will make complete sense to you but not to others.
  • It will take you longer than you think. Trust me - it will. And writer’s block is a pandemic. Everyone gets it for a bit. Don’t worry unduly.
  • Thank your family in the credits for putting up with you being a hermit as you finish the book. This helps a lot. Or go one better, as Chris Sells did recently.

Book writing is a bit like cramming for an exam in some ways. The best way to produce cogent text is to be on top of the subject you’re covering and let it flow - in a structured way. Braindumping everything you know on a subject into a splurge and calling it a chapter isn’t as good.