BlackBox

I promised I’d update everyone with my progress using the Pomodoro Technique, so here it is. This reporting covers the period from last Friday, Oct. 23rd, to Thursday, Oct. 29th. It’s hard for me to see any patterns yet as it’s only been a week, but I’m posting up my two graphs for analysis.

Scheduled and Unscheduled Pomodoros with Completed Tasks

The first graph is comprised of my scheduled, unscheduled, completed Pomodoros, and completed tasks (tasks that I finished with a set of Pomodoros). You can see here on days 3 and 4 I got a little overambitious with how many Pomodoros I would complete, but you can also see on those days my completed Pomodoros went way up as well. Not sure if there is a correlation there yet or not.

Pomodoros Internal and External Interruptions

The next graph is my tracking of internal and external interruptions. As you can see, I’m still working on controlling my interruptions during a given Pomodoro.

Now, this week was a bit of an oddity because most of my co-workers were out sick at one point or another during the week, so I was able to concentrate (when at work) a lot better. Next week will be the real challenge, but I do feel better having gotten into the groove of it, so maybe next week will be ok.

There are some items that I’m tracking that I’m not sure what to do with yet:

• Estimate vs. Actual Pomodoros per task – I have several tasks that I’ve completed and marked how many Pomodoros it actually took me to complete. Not sure if I should be putting this into a spreadsheet and if so, how should I track it?
• Combined tasks – I mark tasks that I’ve combined into one Pomodoro, but again I’m not sure if I should do anything with it.

My goals for next week are:

• Start figuring out how to integrate this technique with OmniFocus and some general task management. This is going to have to happen soon, as I have too many papers floating around right now. But I need to figure out how I’m going to track interruptions, scheduled, unscheduled and completed Pomodoros, etc.
• Improve my average daily Pomodoro count. The max I can do in any one day is 20 (during the week), and probably closer to 24 – 26 for a weekend (if all I did was work, which I won’t do). My max count for the highest day was 13 completed Pomodoros. My average Pomodoro count for the week came to 7.29 or roughly 7 completed Pomodoros a day (3 1/2 hours of sit-down, concentrated work). I’d like to see if I can get that average up to about 10 Pomodoros a day for the week.
• Improve my interruption rate. I can easily control my internal interruptions I just need to get a handle on it and write down all the little things I want to work on so that I don’t distract myself during the current Pomodoro. External interruptions I am still working on handling. We’ll see how next week goes.

A few final notes on integrating the Pomodoro Technique with my life (and other task management):

When I’m working on code stuff, I eventually do get to the point of attempting to build it on our build server. This can easily take more time than the length of one Pomodoro. But I hate to break the groove and go work on something else that will take more than one Pomodoro. And of course if the build fails, I need to figure out what caused the breakage, fix it and attempt to build again (another delay). One thought I had for taking up the rest of the remaining Pomodoro was a quick code review, but I’m not sure how far I should carry that. Or should I keep a list of quick tasks (that I can complete in one to two Pomodoros) that aren’t time-sensitive I could do while code is building and I’m waiting?

Second, how do you handle tracking things like errands using the Pomodoro Technique? Or do you? I’m thinking that Pomodoros are best when you need to either sit down and do something at your desk or at home (like cleaning, organizing, etc.) and not for running errands or shopping. It feels like a system for managing a set amount of time working on something within another system, perhaps.

Again, if you’ve tried Pomodoro in the past, I’d love to hear your impressions on it in the comments below! Especially if you’re a programmer – I’m very curious to see how other programmers have used this system.

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.)

1. 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.)
2. 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.)
3. StoryMill – I’m not very familiar with this tool, but a here’s a review. (Special deal for NaNoWriMo participants.)
4. Ulysses – Here’s a review of it. (Special deal for NaNoWriMo participants.)
5. Nisus Writer Express (or Nisus Writer Pro) – Here’s a review of Express.
6. Copywrite – Here’s a review.
7. WriteRoom – This is a bare bones “just write it” editor. Nice to take away all the distractions and focus on writing.
8. TextMate – This, combined with some of its plugins make this a very good tool for writing a tech book.
9. 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.
10. 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.
11. 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.

1. 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.
2. 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.
3. 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.
4. 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!