Python Programming, news on the Voidspace Python Projects and all things techie.
Writing a Technical Book
Any day now I will get the first quarter sales figures for IronPython in Action. That will mark the book having been actually in the hands of readers for three months and also be about two and a half years since I first contacted Manning about the possibility of writing an IronPython book for them.
I've written up my experiences of writing a technical book, including my justification (uh, I mean explanation) of why it took so long, the writing process, things I learned and contract advice for the aspiring writer. This is advice I didn't follow myself but wish I had...
Much of the article is specific to my experiences with IronPython in Action - but despite the difficulties (and there will always be difficulties) I still recommend Manning if you really have to write a technical book:
The most important thing I learned was don't sweat the small stuff. This warrants repeating. Don't sweat the small stuff. Many times I knew the gist of what I wanted to say in a passage but couldn't find the words. I would go round and round over a single sentence for fifteen minutes or more. This happened a lot. I learned to just write something and then come back to it later. Often what I had been unhappy about when writing read fine when I came back to it the next day. If I was really stuck I would just leave a placeholder (like XXXX or something easy to search for) and come back to it another time. Letting yourself get stuck drags out the writing process and makes it mentally exhausting. Far better to just write what you have and move on; you're going to be going back over it later anyway.
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.