The Messy Notebook

I used to hate public speaking. Sweaty palms, stomach aches... the works. However, over the last year or so I finally got over it. Speaking to a big room of people simply doesn't bother me anymore.

It somehow happened over a relatively short period of time. I talked this over with a friend recently: "what changed?" I think the following three points did the trick for me:

Know your material inside out. Throw away your index cards, force yourself to really internalize your material before presenting it. Mastery breeds confidence.

Practice practice practice. Every time you speak you'll improve, and you'll get a little more comfortable each time. Super obvious point, but speaking regularly does diminish the fear of it.

Set it in perspective. I think this was key for me. I've had several scares at the hospital during the last year (unfounded ones, fortunately!) Now I use that experience to ground myself before speaking. Compared to the loss of a loved one, how scary is it really to get up in front of a crowd of peers? "Remember that hospital waiting room? This is peanuts in comparison! Sack up, dude!"

Perhaps some of these measures will work for you as well?

I'm starting to fall in love with Clojure, and I'm having lots of fun learning the basics of it. The best way to get up to speed in new programming language is to write something useful, so that's what I'm currently doing.

My first crack at a Clojure program is a simple auto-testing tool. I like test-driven development, and I wanted a light-weight way of running my clojure unit tests continuously in the background. If I break a test, I want to find out at once. When I fix the error I want a confirmation of that as well.

An autotest workflow is extra useful when learning a new language - in that situation you should take extra small steps, with very rapid feedback cycles guiding your way.

This is what it looks like:

Keep in mind that this works best with lean, rapid unit tests (measured in seconds, not minutes). Massive fifteen-minute test-suites defeats the purpose of autotesting.

The algorithm is trivial: a one-second-interval loop that scans for changes to source files in the project directory. If file timestamps change or new files are added, a test run is triggered. The result of the test is determined by scraping the output of the terminal. The terminal is then colored green for test success or red if anything fails (I use tiny osascripts to color the terminal in different colors).

Source code:

(ns com.thomanil.autotest
  (:require clojure.contrib.shell-out))
 
(use 'clojure.contrib.shell-out)
 
(defn cmd-line [command] (sh "bash" :in command))
(defn clear-console [] (println (cmd-line "clear")))
(defn visually-indicate-test-running [] (cmd-line "osascript bin/testrunner/make-term-yellow"))
(defn visually-indicate-success [] (cmd-line "osascript bin/testrunner/make-term-green"))
(defn visually-indicate-failure [] (cmd-line "osascript bin/testrunner/make-term-red"))
(defn visually-indicate-exception [] (cmd-line "osascript bin/testrunner/make-term-red"))
(defn all-source-files [] (seq (.split (cmd-line "ls **/*.clj") "\n")))
(defn all-test-files [] (seq (.split (cmd-line "ls test/*.clj") "\n")))
(defn file-state [file-path] (cmd-line (str "ls -l -T " file-path)))
(defn state-of-src-files [] (map #(file-state %) (all-source-files)))
 
(def run-cmd "java -Xmx1G -cp lib/clojure.jar:lib/clojure-contrib.jar:.:classes clojure.lang.Script ")
(defn run-tests [] (cmd-line (str run-cmd (apply str (interpose " " (all-test-files))))))
 
(defn set-console-state [test-result]
	(let [test-status (get test-result 0) test-output (get test-result 1)]
		(when (= test-status :success)
			(println test-output)
			(println "ALL TESTS SUCCEED")
			(visually-indicate-success))
		(when (= test-status :failure)
  			(println test-output)
  			(println "SOME TEST(S) FAILED")
  			(visually-indicate-failure))
		(when (= test-status :exception)
			(println test-output)
			(println "EXCEPTIONS OCCURRED")
      		(visually-indicate-exception))))
 
(defn exception-or-failure-in-text [result]
	(cond
		(.contains result "Exception in") :exception
		(.contains result "FAIL in") :failure
	 	(.contains result "0 failures, 0 errors") :success ))
 
(defn determine-test-status []
	(clear-console)
	(let [result (run-tests)]
		(let [state (exception-or-failure-in-text result)] [state, result] )))
 
(defn run-test []
	(visually-indicate-test-running)
	(set-console-state (determine-test-status)))
 
(def monitored-files (ref (state-of-src-files)))
 
(defn files-changed? []
	(let [current-state (apply str (state-of-src-files))
		  last-state (apply str @monitored-files)]
			(if (not(= current-state last-state))
				(do (dosync
					(ref-set monitored-files (state-of-src-files)))
					:true)
				nil)))
 
(defn test-loop []
	(loop []
		(if (files-changed?) (run-test))
		(Thread/sleep 1000)
		(recur)))
 
(run-test)  ;Do first test no matter what
(test-loop) ;Wait for changes in files to trigger new tests

Disclaimer: Some of the above is probably not idiomatic Clojure code, since I'm still very much a novice in this language.

I'm not a great teacher. I don't have any special instructor credentials. I have, however, attended some bad technical presentations in the past, so I know of some common problems. Fortunately they're not too hard to fix.

I recently held a programming course of my own. Resolved to avoid as many pitfalls as possible, I invested some time to properly market, prepare and present my class. These are some principles and techniques which seem to work well.

MARKETING

Start with basic market research. Consider your intended audience - what are they likely to want from the workshop?

Write a carefully worded invitation to the course. Create a proper pitch - sell it well! Standard principles of marketing and copywriting apply: state why the reader should care (the benefits) before listing concrete curriculum and details (the "features").

Announce the workshop in a wide range of channels: face-to-face, email, social media... the more the better.

Make sure it's easy to sign up. Think of it like converting prospects to customers - make the "buy" threshold really low for potential pupils.

Once signed up, contact participants individually well before the workshop. Send reminders and practical info. Also, try to gauge their experience level and interest in the subject of the class. This lets you tailor your material to the audience beforehand.

PLANNING & STRUCTURE

Again, think about your target audience - after the steps above you should have a better idea who will show up. Generalize this into personae - which archetypes of people should you prepare for? Can you tweak the workshop to offer something to both Pro Programmer Penny and Middle Manager Mike, if both kinds of people have signed up?

Think through the overall structure and syllabus of the workshop thoroughly. Use flexible techniques like whiteboarding, sketching and mind maps to brainstorm scope and content. Like software development, missteps are much cheaper to fix in the initial planning stage.

How will you teach? A range of methods works best, if you have time for it. Some lecturing, some "show and tell", some "try yourself". Each individual attending has her own way of learning - try to present the material in several ways to cater to everyone. Don't worry if this duplicates a lot of material; repetition aids memory retention!

Present both core facts and related context. In other words, present both "what it is" and "why you should care". Micro and macro.

Your audience will have varying levels of expertise and aptitude in the material you are teaching. Try to cater to both the experienced student as well as the total novice, if both are likely to attend.

I like to start workshops with a lecture to lay some foundation, with plenty of live demos and moving examples along the way. Then I move on to practical exercises. In short: talk about it, show it, let people try it. Note: the rest of the article assumes this workshop format.

THE SLIDES

Start strong. Present a clear agenda - "what are we going to learn today?". Keep your personal introduction brief; people care about what you intend to teach them, not your credentials.

Avoid long rambling slides. Short slides are good, one-word slides better, a simple picture is best. Many succinct slides are better than few, text-heavy slides. Make. As. Short. Points. As. Possible. Each slide then serves as a very precise prompt for you, making you less likely to ramble and forget your next point.

Your slides don't need to be works of art, but do use some basic techniques of graphic design:

• Decide on overall style beforehand in order to make the slides as consistent as possible.
• Use large fonts with high contrast colors. How will your code, text and video look when projected on a canvas? In normal daylight? From thirty feet away?
• Use repetition. Content which repeats sticks in your mind after a while.
• Use contrast. Content which stands out is memorable.
• Employ evocative, high quality images. Avoid bland clip-art.
• Write short, to-the-point text with plenty of whitespace around it.
• Drop the standard company-branded powerpoint template. I'm sure your official company stationary is nice, but it simply adds clutter beyond the first slide. Limit your marketing and branding to the introduction and conclusion.

THE EXERCISES

Prepare to spend a lot of time creating good practical exercises! Some factors to consider:

• Assignments should start nice and easy to give a sense of accomplishment. Make the pupil feel awesome!
• Each exercise should be focused on teaching a single thing, and it should be obvious what the student is learning. "Why it this awesome?"
• Create a wide range of exercises, make them possible to solve in any order. A long chain of cumulative exercises is vulnerable to "blocking". Instead, make it possible to jump to something different if the pupil gets stuck.
• Provide for a wide range of expertise in audience. Cater to both the star pupils and the less experienced. One way of doing this is to add "extra credit" parts to every exercise.
• Demand little to no preparation from students before the workshop begins. Instead, make it really easy to get started during the actual session. Think user experience!
• Don't assume reliable internet or intranet access during the workshop. Instead, provide tools, documentation and cheat sheets in the exercise handout.
• Make sure it's easy to distribute the files and tools to the students. Buy a bunch of usb sticks, preload them with the handouts before the workshop begins.

ITERATE & PRACTICE

Once you have the basic structure and content in place, set aside plenty of time practice, tweak, practice, tweak. Iterate and internalize the material. Like any other writing process, your material improves as you return to it repeatedly with fresh eyes. Make sure to leave time for the material to "breathe a little" in your mind before the big day arrives.

D-DAY

Arrive early. Survey the room, set up your own laptop, make sure the light level is under control. You don't want to burn time hunting for light switches, cables and curtains once the workshop starts.

When people start arriving, greet as many as you can at the door. Get some smalltalk in before the actual workshop starts. You need to build rapport with the audience as quickly as possibly in order to engage them, so reach out to them at once! Don't like public speaking? You'll find it much easier if you already have some friendly faces in the audience before your presentation begins.

Now for the hard part (at least for me): the lecture. Strive for a relaxed and clear presentation. Control your body language. Keep a steady, calm pace. Like a singer or a martial artist, use your stomach: breathe and speak from your gut, don't squeak from your throat.

Engage your audience. Ask both retorical and actual questions to the room. Have people answer with a show of hands, individual answers or group discussion. Participation is good!

Take short questions as you go, refer longer discussions to a QA session at the end - or possibly one-on-one email correspondence after the workshop ends.

Structure your talk in short sessions with plenty of breaks, say 30-45 minutes with 5 minute breaks in between. Make the sessions even shorter if the venue is small and cramped - the crowd will quickly use up the fresh air.

Pay attention to your audience. If the seem bored, speed up. If they seem to "fall off", slow down.

Hand out slides and exercises after the lecture - not before. With a bunch of laptops and cellphones in the room, you're already fighting for the attention of your audience, so don't undercut yourself further by giving them something to read while you're talking. Control the message. You want their focus on you and the big screen.

During the practical exercises, actively circulate, talk to students, gauge their progress. Offer to help. It's easy to ask questions to an instructor who is present and attentive. A teacher sitting behind a desk fifteen feet away? Not so much.

Finally, solicit feedback from the audience at the end of the workshop. What worked well? Which parts of the workshop felt weak? Why?

Take their feedback to heart, and give an even more kickass workshop the next time!

REFERENCES

Presentation Zen (Amazon)

The Copywriter's Handbook (Amazon)

Creating Passionate Users

TedTalks

Tim Ferris on public speaking

Special thanks go out to Siv Fjellkårstad, Johannes Brodwall, and Markus Krüger for material and feedback for this article.

I've created a free, downloadable workshop for you. It introduces you to the skills, tools and techniques of modern JavaScript development.

The workshop takes roughly half a day (3-4 hrs) when presented properly, with equal parts presentation and practical exercises. You can use the slides and exercises as a personal study aid, or you can arrange a proper workshop for your own colleagues or clients. Alternatively, contact me. I'm able to hold the workshop on-site in and around Oslo.

DOWNLOAD HERE (slides, lecture notes, exercises, solutions, examples, tools)

A code kata is a short programming task. Its purpose is to let you practice tools and technique. You pick a relatively small problem and practice it repeatedly. Since the task is small, you free yourself to focus on technique and speed, tools and workflows, as opposed to active problem solving.

I was inspired by the "katacasts" of Uncle Bob as well as my friend Johannes, and decided to do one of my own. I chose a very simple task for this clip: the FizzBuzz interview question.

Print digits from 0 to 100. For every digit which divides with three, print "fizz" instead. For digits dividing with five, print "buzz". For digits which divide with both, print "fizzbuzz".

My solution, as shown in the video below, was meant to accomplish two things:

Demonstrate simple TDD workflow in JavaScript. Many software developers tend to treat JavaScript as the redheaded stepchild of programming languages. We unit test our "real" code (Java, C#, Ruby, whatever), but for some reason, that tends to go out the window when we switch to JavaScript. This is a shame; automated regression testing becomes extremely useful once your JavaScript code grows into hundreds or thousands LOC.

Improve my technique and speed in my editor of choice - TextMate. I'm trying to use the mouse as little as possible, can you tell? I still consider myself fairly slow in TextMate, but I improved while practicing for this screencast.

Note: I generate a tiny development environment in the beginning of the clip. This setup is something I've put together for a JavaScript course I'm holding internally at my workplace. The environment is meant to get you started quickly with good practices and useful tools (like YUI Test, jsLint, jQuery). I'll probably turn it into a tiny open source project once it's somewhat more stable. Feel free to tweet me if you want a look at it.

The clip was shot using SnapzProX on OS X 10.6.2. I edited the clip with Final Cut Express. No changes were made to the kata footage itself - I only added music and intro/outro screens.

For the past couple of months I've worked on a nontrivial project: build, launch and sell a commercial product on my own.

I set fairly strict constraints for the project:

• Use less than five months to release the first version.
• Work on it no more than fifteen hours a week (nights and weekends).
• Don't neglect my family, which I love.
• Keep my dayjob, which I really enjoy.

Well, I did it. The result is ThoughtMuse, an online mindmapping tool which runs in your browser. I released v.1.0 a week ago.

It's early days.  ThoughtMuse has some rough edges which I need to improve, and there's plenty of additional features I'd like to add to it.

So do I have any paying customers yet? Well, the magical first sale ticked in a few days after launch; the sweetest $35.40 I've ever earned. Building and selling something on your own is extremely rewarding. Making a profit? Sure, that would be nice as well.

You learn a lot by building a commercial product all on your own. I'm going to write more on this later on.

The magical first sale ticked in a few days after launch. The sweetest $ 35.40 I've ever earned, and one of the most rewarding moments I've had as a software developer. Building and selling something all on your own is extremely rewarding in itself. Making a profit? Yes, that would be nice as well.

Three months ago I stumbled across a time management system called 'The Pomodoro Technique'. I really liked it due to the immediate productivity gains it gave me. I thought I'd follow that blog post up with my current impression of the technique, now that I've used it for a while. Todays blog entry will make more sense if you read my the original post first.

Recap

The idea of the Pomodoro Technique is that you work in timeboxed intervals of 25 minutes. Each interval is called a "Pomodoro" (tomato). Once you've completed a pomodoro you make a note of it, and take a five minute break. After four pomodoros you take a longer break.

The Good

I'm ultra focused when I work on tasks using this system. I initially found the ticking egg timer somewhat distracting and stressful, but that passed after a week or two. Once I start the clock I'm usually able to enter a state of flow really quickly.

I've repeatedly seen clear benefits from the self-enforced breaks; they sometimes make me step back, rethink and adjust what I'm working on. This has prevented me from going too far down some potentially time-consuming dead ends.

Recording completed pomodoros forces me to document and take stock of how much time I spend on different tasks. This provides historical data which really helps when I estimate similar future tasks.

"I'm going to complete a few eggs, dear" has become a catchphrase at home (eggs = egg timers / pomodoros). It's a clear way of communicating to my fiancè that I'm setting aside a concrete amount of time for work. This lets her know exactly when I'll emerge from my cave again.

The Bad

It's hard to stop working once the egg timer rings. This is especially noticeable if I'm almost done with a task; it's very tempting to put a few more minutes in before I take that break. Of course, those "few minutes" sometimes end up taking an hour or two...

The technique forces me into a certain mindset. I become really focused and efficient, which is great for concrete, well planned tasks. It's not always suitable for more reflective and explorative work, though. I find I do better at things like research, brainstorming, design and general planning when I'm not under the gun of my egg timer.

I have not used the technique seriously at my dayjob yet. I'm not using a mechanical timer there, since a ringing egg timer would be quite distracting for my coworkers (several of us share an office). One solution: use headphones combined with a software-based timer instead. Unfortunately, I find tools like mytomatoes.com much less effective than a mechanical clock; the "break" audio signal is far less noticable, and it's often lost on me because I take off my headphones or listen to music while working.

Conclusion

The Pomodoro technique has boosted my productivity, and I highly encourage more software developers to try it out. I will keep using it for my side projects. It has been less useful at my dayjob, but I'm going to try to adapt it to work well there as well.

Starting a new pet project is easy. But finishing it? That's a different story.

Many programmers love to tinker with side projects. I'll argue that most of the decent ones do, anyway. Learning new tools makes us want to build things. Innovative technologies, cool product ideas. Unfortunately, the result is usually just a sad collection of forgotten files on some hard drive.

I'm certainly no exception to this - my portfolio isn't exactly jam packed with polished results. I've worked up enthusiasm for a variety of hobby projects over the years, with somewhat spotty follow-through.

Recently, however, I decided to step it up a notch. "This time I'm going to stick with it until I end up with a real product." So I did. I bootstrapped ThoughtMuse, an online mindmapping tool,  in under five months using only my spare time during nights and weekends.

To keep development of my product rolling I try to consistently apply basic productivity techniques. They're not particularly new and amazing methods - many of them are just Project Management 101. Unfortunately, they often seem to go straight out the window when programmers sit down to work on their own time. Perhaps using basic project management practices makes pet projects feel less sexy, somehow?

Anyway, these are some of my favourite techniques to keep producing in my spare time.

Set goals

Stating exactly what you want to achieve motivates you and focuses your efforts. And no, saying that you "kinda want to build this thingamajig" won't cut it. Be specific. Quantify. What am I creating? For whom? By when? What, and how much of it, do I need to achieve? Write down concrete, measurable objectives.

Divide into milestones

If your project will take more than a few weeks it's crucial that you divide the work into separate deliverables. Always having a single enormous blob of work left is demotivating. Instead, structure your project as a collection of smaller increments. And reward yourself every time you complete one of them!

Make yourself accountable

Tell someone what you are doing, and keep people informed of your progress. Talk to friends, post progress updates on your blog, whatever. The idea is to set up a small amount of external pressure to keep you going when the chips are down. I told Bob that I'd finish this cool widget by March - so I'd better get cracking!

Something every day

You need steady momentum to keep the project rolling. It's much harder to sit down and work if you only do so every other week - you then need to use more time and energy to "spin back up" every time. You also run a higher risk of falling off the wagon completely if you miss one or two  of those long sessions. Instead you want to ingrain a steady, regular habit which feels as natural as brushing your teeth every evening.

Don't force it

Like woodworkers say: don't work against the grain. If you hit a serious wall in some task, switch to something completely different to keep your momentum going. There's always other stuff that also needs to be worked on. Some code proving hard to debug? Jump to, say, user interface design instead. Then come back to the original problem later on. Problems have a way of solving themselves if you let your subconcious chew on it for a while.

Iterate, iterate, iterate

You won't get every task right the first time. Allow yourself to come back to each area of your product multiple times with fresh eyes. You'll see more clearly the second and third time you return to that piece of code or functionality.

Sustainable pace

Slow and steady will get you there in the end, full sprint might not. I think that taking the tortoise route is the safest approach. Avoid burning yourself out by overworking. This is especially important in the beginning when you have lots of enthusiasm. You will feel less optimistic in a few weeks or months, it's just a matter of time - so pace yourself.

Timebox everything

Perform an initial rough estimate of how much time and effort the project will take, given how ambitious it is. Then set aside fixed amounts of time you are willing to spend on your project. "I have to be done in three months, using no more than ten hours a week". Work on each specific task for set amounts of time.  This maximizes your focus. Timeboxing is especially useful if you're in a relationship; your girlfriend/boyfriend/wife/husband/children will thank you for this one.

Ruthlessly trim scope

This is the flip side of the technique above. You now have strictly limited time to burn on the project, so get the most out of your available hours. We have a tendency to get carried away, dream up new features and let the scope of our projects grow. Try to constantly remove instead. Paraphrasing Einstein: "Everything should be made as simple as possible, but not simpler." Do you really need this, that or the other to be satisfied with the finished product? If not, just archive the idea, then move along.

Let life intrude

Accept that Everyday Life can and will mess up your schedule sometimes. That's ok. Don't stress out about it - as long as you're moving forward you'll get there eventually. Just keep plugging away. Stick with it!

I've described the techniques above in the context of software development, but they should be fairly universal and applicable for anyone practicing some sort of craft in their spare time. If you have any other methods which work well for you, I'd love to hear about them!

Are there areas in which any of these techniques don't work or are actually harmful? I don't know - feel free to tell me if you know of specific counter-examples.

Now, time to get back to work on that cool new feature...

How do you determine how long something will take to build?

In an ideal world, many of us would probably like to simply work until the stakeholder/product owner decides we're done, keeping our expense meter running all along. This is (very roughly) the approach taken by agile software development methodologies such as Scrum.

Unfortunately, in the real world we often need to know roughly how long something will take before we start working on it. This is basic product management: the feasability of a new project, product or feature is (in part) derived from the initially estimated cost of building it. "That new nifty feature will take more than four months to add to our product? Maybe we have better things to do with our time, then."

What's the best way of doing this up-front estimation? There's certainly lots of approaches out there. Personally, I've settled on the following method:

1. Start by getting your bearings somewhat. This means doing enough design and requirement gathering up front. Talk to stakeholders and users. Play around with any new unfamiliar technology that the work will require.   

2. Extract the concrete tasks that must be done. Each task should take less than eight ideal hours to complete (see below). Tasks larger than this are often opaque "lumps" of many tasks, which are harder to estimate accurately- so divide the work into subtasks as needed. Don't forget work related to polish and testing: integration testing, documentation, release routines, etc.  

3. Estimate each task in ideal hours: "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate using abstract or relative units, before translating to actual ideal hours. The Poker Planning Game and the Pomodoro Technique are good examples of this approach.  

4. Add up total ideal hours. Then multiply by a risk factor, to allow for Murphy's Law. My personal minimum is usually 1.2 (20%) - and that's if I have a very good handle on both the technology, the requirements and most other significant factors.  

5. Figure out how many ideal hours you actually get done each week. How much effective time do you really have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week. Now you know roughly how many actual hours the work will take.  

6. Finally, take external dependencies into consideration. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Set up the project schedule based on these known constraints.  

This method is heavily inspired by Mike Cohn's Agile Estimating and Planning, and I use it both at my dayjob and for private side projects. I've found this to yield quite accurate estimates for small projects - eg. where the scope is less than, say, 3 months with less than four developers.

For larger projects you may find that estimating work up in such fine grained tasks involves a lot of uncertainty. "How can I know exactly what specific tasks will be required all through my project?". Well, yes - for projects with larger scopes, this quickly turns into riskful guesswork.  This is what makes estimating entire large projects up front (and, by extension, taking on large fixed cost projects) such a dicey proposition.

It's evening, and my home office door is closed. No email or IM clients are running on my computer. My daughter is asleep, my Significant Other is aware that I'm working. I wind up the egg timer, the clock starts ticking. My mind quickly enters a state of Flow. 25 minutes later the timer rings. The feeling is akin to waking up from a dream. I stop working, and jot down a mark in my task list. A solid unit of work accomplished; another egg completed.

I have trouble maintaining a consistent level of productivity - especially for side projects that I work on in my spare time. Both at work and privately I find that my productivity fluctuates wildy. Sometimes I'm able to crank out quality stuff for 10 hours straight, while other days simply vanish in trivial distractions.

A possible remedy to this problem presented itself recently in the Pomodoro Technique ("Tomato Technique"), a time management method I'd never heard of before last week. I've currently only used this system for a few days, but the early results are quite promising.

Getting started is fairly simple:

1. Set up some sort of timer. A software clock works, but a physical clock is better.
2. Select a task that you need to accomplish, and remove possible distractions.
   
3. Set the timer to 25 minutes.
   
4. Work on the task until the timer rings.
5. One "tomato" is now accomplished for the task - add a mark to the task record.
   
6. Take a short break before restarting the timer - 5 minutes or so.
7. Take a longer break once every four tomatoes.
   

To me, the most obvious benefit of the technique is that it forces you to timebox and really focus on your work. One resulting effect for me is that I get into the elusive "flow" state much earlier than before. There's more to it, though.

The regular breaks provide an opportunity to periodically step back and look at the current task from a different perspective: "Am I going about this in the wrong way? Maybe I'm even solving the wrong problem?" This is valuable - it's easy to lose sight of the larger picture when you're head down into the specifics of a task.

Over time your ability to estimate future tasks is likely to improve, since you have a more solid appreciation (and written record) of how much effort your past work took. Besides, it's generally a good idea to measure your work in abstract work units rather than directly in clock hours (the Poker Planning Game is another example of this phenomenon).

The final benefit of the system is the moral boost you get from continuously marking down those completed "tomatoes" (I personally refer to them as "eggs", since I use an egg-shaped timer). Think about it; don't you feel good when you complete a feature, article or bug fix? I find that this technique gives me that same satisfaction every 30 minutes - I may not finish that new feature tonight, but I know that every egg takes me closer to completion.

It will be interesting to see what this does for my productivity long-term. The next step in the technique is to actually start estimating future tasks in tomatoes instead of hours; I'll try that once I've gotten used to the basic workflow. I'll probably post an update in a few weeks.

If you found this interesting I strongly encourage you to visit the Pomodoro website and read more yourself; there's a nice, free eBook summary available there (pdf).

UPDATE: I wrote a follow-up post a few months later.