Managing time 2005-04-20


One of my biggest challenges has always been managing my time. The main reason is because by nature I'm all over the place. If you've read my rants on RDF, parsing technology and the DOM for instance, you might have noticed how I started looking at RSS, decided I wanted a better C++ DOM parser, started playing with RDF and Turtle, got sidetracked into writing a parsing tool to help me write a Turtle parser, started writing a BNF based parser generation tool, before I started unwinding the stack, working my way back down to the original goal.

Eventually I'll get there, but while the above approach works fine for what is essentially a learning experience and a hobby, it does not work fine in a job setting where you need to deliver.

To me, these are the essential tools to managing my time:


  • A TODO list

  • A daily schedule

  • A list of what I've actually done

  • Keeping and maintaining a todo list makes it harder to brush tasks under the carpet. It forces me to realise how much stuff is waiting to be done. Let it grow, but prioritise so that you don't get overwhelmed by the choices.

    However, a todo list in itself is easy to ignore - I can easily just spend a day fiddling with other stuff and never once look at the todo list. Which is where my daily schedule comes in. It's something I started doing relatively recently, but which works wonders whenever I'm not motivated to work:

    Every morning, I sit down and pencil in time slots for what I want to do when during the day, including things like "update and review todo list". I take care not to fill everything, because something always pops up. But setting myself definitive deadlines helps contain "dead time" to small well contained breaks spread through the day.

    It also helps contain time eating bullshit like checking your e-mail every two seconds to within pre-allocated slots. If something is too important to wait until a slot 2-3 hours away, people will call you - there are simply no excused for continuously checking your mail.

    The last item, keeping a list of what I've done is mostly for my conscience. If I see it doesn't fill up, I start thinking about how I'd justify it if asked. It does wonders for actually making sure I spend my time doing stuff I can justify spending time on.

    The list is important for another couple of reasons as well: It helps me improve my time estimates by documenting how much time something really took, and it helps me documenting the effort I put in at work in case I'm ever in a situation where it's clear my effort isn't been noticed.

    I'm doing that one out of experience - it's far too easy for people not to notice what you're doing, in particularly when you're doing it well and everything is going smoothly and people don't see you or your team running frantically around. Once that happens, you don't want to have to spend a lot of time digging up documentation to show what you were doing. You'll be far better off being able to present detailed notes day by day documenting it all, and chances are those notes can help head of what could easily become a deep conflict.

    A more macabre reason to keep detailed notes, including the list of what you're doing daily, is the big red bus scenario. That is, you step out in front of one. The better you are at documenting what you do, the better the company will be off.

    And while you might not care how the company will do if you are dead, think of it as setting a good example, in particular if you manage a team: within software engineering in particular there's way too little appreciation of the time honoured science practice of keeping a detailed journal of what goes on.

    Having your team members take up the practice can easily save your ass down the line when one of them decides to take off with no warning, dies or ends up in hospital for an extended stay, is brutally wrestled from your team by another department, or otherwise becomes unavailable.

    Good advice.

    Even better for people like us is to keep two to-do lists. One has your actual tasks ("Write research group Website"). The other has the tasks you're doing as you build up the stack ("Fix CL-WHO to generate correct quotes in XHTML", "Finish grand unified RDF exporter").

    It's all very well making progress, but I find it far to easy to make progress on general, abstract frameworks and not my end goal!

    I guess what we really should do is keep an RDF to-do graph.... :)


    blog comments powered by Disqus