First we had NaNoWriMo (National Novel Writing Month), then NaNoDrawMo (National Novel Drawing Month), now we have PragProWriMo (Writing a Tech Book for the month of November – named after Pragmatic Programmers, a tech publisher).
So, I thought I’d share a few writing tips for those of you attempting to write a tech book this month. There are also some great tools out there that you might not be aware of. I’m not familiar with all of them, but I’ve provided links and reviews for you to make your own decision.
Tools
(Apologies in advance, I’m a Mac person so most of these tools are for Mac people – sound off in the comments for other platform-specific tools you use.)
- Scrivener – I like this app a lot so far, because it’s great for collecting bits and pieces together and organizing your thoughts into chapters as you write. Here’s a longer review of it. You get a 30-day evaluation license (and I mean 30 days of writing, not from when you open the application). (Special deal for NaNoWriMo participants.)
- Storyist – This is one I would like to try, and I’m glad they’re going with the 30-day evaluation license as well (not sure if it’s like Scrivener’s 30 days of use license or not). Here’s a review of it. (Special deal for NaNoWriMo participants.)
- StoryMill – I’m not very familiar with this tool, but a here’s a review. (Special deal for NaNoWriMo participants.)
- Ulysses – Here’s a review of it. (Special deal for NaNoWriMo participants.)
- Nisus Writer Express (or Nisus Writer Pro) – Here’s a review of Express.
- Copywrite – Here’s a review.
- WriteRoom – This is a bare bones “just write it” editor. Nice to take away all the distractions and focus on writing.
- TextMate – This, combined with some of its plugins make this a very good tool for writing a tech book.
- Pagehand – This looks like a very interesting Word Processor. Not sure if I’d use it to write a tech book. It does look like it could handle layout a lot better than Word can, though.
- Microsoft Word (or free alternative OpenOffice.org) – Honestly, I’ve written two tech books in Word, and I would not recommend it to anyone. It is absolutely horrible. Don’t do it. Save yourself some pain and anguish, seriously. I don’t know about OpenOffice, but I would imagine it would be similar. This leads us to our next question – choosing your format.
- Emacs or vi – I’m not even going to go there. If you know what these are then you’re already using them (or decided not to).
What format should I write it in?
Ok, so if I’m not going to write this in Word, what do I do?
There are several format options available to you to write your tech book in.
- First up is DocBook or Simplified DocBook, which is an XML format. It was meant for writing books in. There are stylesheets available that will convert your book over to PDF format so you can see what it will look like written out.
- LaTeX is a document preparation system (which to me means you shouldn’t be writing in it) and is for the hardcore geeks among you. I wouldn’t write a book up in LaTeX myself, but if you like it and want to do it that way, go for it. Personally, I’d rather convert a DocBook document to LaTeX, and then take LaTeX to PDF.
- Scrivener has built-in support for the MultiMarkdown format, which is an extension of Markdown. This is a nice, lightweight format that is easily transformable to PDF.
- No formatting at all. This is certainly an option. Just write, get your words (and code) on paper and format it later.
How do I write (or choose what to write)?
Hopefully you already have something that you’re passionate about. If not, then I would recommend you not undertake writing a tech book. It is truly a labor of love and passion. Your passion shows through in your writing and helps readers become involved in the story of becoming a better programmer, sys-admin, photographer, etc. If you aren’t passionate about your subject, then that will show through too and your book won’t be successful in getting your readers fired up about the topic.
That said, first you should read Dave Thomas’ series on technical writing. Here are some highlights from that series. Once you’re done, come back here for some more tips.
Ok, all done reading the highlights? Good. I also recommend the “Code first, write later” technique. With this technique you pick a project that you are going to do from start to finish with the reader, walking them through the basics and helping them learn some things along the way.
Finally, we get down to the actual business of writing the book itself.
- Never let the well run dry – This tip came from Hemingway, and I applied my own technique to it.
- Use a time management technique to focus on writing – Using something like the Pomodoro Technique can help you during your writing phase. Just write for 1 or 2 Pomodoros (1 hour), then up it to 3 or 4. If you feel like doing more (and you can), go for it! See how much you can get written that way.
- Set daily and weekly goals – Start small at first, then increase. Don’t try shooting for 10 pages a day right away, get a feel for how much you can actually do. 2 or 3 pages a day to begin with is a decent pace for a tech book. Once you set your goal, track it to monitor your progress.
- Track progress on your goals – Just as with any goal, if you aren’t tracking your progress, how can you know if you are going towards it or away from it? Of course that means that your goal itself has to be trackable in the first place (see SMART goals for more information on setting goals).
- Be accountable – Write on your blog or Twitter what your progress is – be accountable to someone besides yourself. This will help you stay motivated and want to update others on your progress (and maybe help motivate them as well).
Do you have any writing tips of your own that you would like to share? Add them in the comments!
