Hanging out on Twitter this morning, @jesseblayne made a remark about getting started. I replied with a more or less a blog post’s worth of info packed into 140 characters. This that blog post.
First, some benefits:
- Writing makes you think, thinking helps you learn.
- Having a list of tasks you know took one hour is incredibly valuable, you know what your time is worth.
- Saves time over the long term. You do your thinking ahead of time allowing yourself to rapidly complete tasks.
I have a system that works really well for me, and could work really well for you. It requires a bit of work, but it’s not hard. And it requires a timer. The work is broken down into hour chunks, and this is non-negotiable. The whole system depends on being able to walk away from a task in an hour.
The system is multi-staged. There is a natural progression from forming an idea to executing it.
Let’s get started.
When I have an idea for something, or I need to get things done, here’s the typical sequence:
- I write, draw or jot down lists on scrap paper. I have a bunch of B5 paper left over from a previous project, or I’ll fold letter size paper in half, 5 1/2 by 8 1/2. Folding A4 in half is B5 is I recall correctly.
- These notes are then (or later) entered into a web application task list. I use the Trac system, same as WordPress (just coincidence, Trac is a good system.)
- The Trac tasks are triaged and refactored into ~1 hr chunks. For example, I’m working on a new chapter for Blog Post Engineering (Repurposing). This was initially entered into Trac as a single task, but that’s too long. I need to spend about 10 minutes and break out all the section of that chapter as separate tasks of about 45 minutes.
- Execute! Once the tasks are chunked down into small pieces, it’s easy to select something interesting to work on.
Write it down
There is something magical about writing things down. It makes us think at the same time as taking action. Synergy. There’s probably weird neurological changes happening, neurons firing, synapses connecting. Or whatever.
All I know is that when I write it down, I learn it better.
I suspect most bloggers are the same (or they wouldn’t be bloggers).
Enter into Trac tasking
I use the Trac system.
You can use anything you want. Basecamp is great system if you’re collaborating; I’m using it for a couple of projects.
The key thing is that following up your writing with a little data entry further locks the task into your mind. It makes you think about what you’re doing. In other words, the data entry itself isn’t all that important, it’s the thinking that’s most important, and entering the task into your todo list (or whatever) makes you think.
Triage and refactor into 1 hour chunks
This is what an hour’s work looks like to me:
- Review previous hour’s tasks, check for pointers to next tasks
- Review Trac tasking
- Do the work. This should take between 30 to 45 minutes.
- Document the work, triage and refactor as necessary. Documentation is best accomplished as you work. It makes it a lot easier to keep track of what got done, and you capture really important details along the way.
- Task out the next hour. Once your finished with the actual work, you should have 2 or 3 little tasks that get you started into the next hour of work. Write these at the end of your hour summary for review the start of the next hour.
Execute!
I cannot explain in words how phenomenally productive this system has been for me. Once the tasking is down at the hour level, I don’t have to think. I know I can pretty much tackle any task and an hour later, I’m done with it. Or if not done, I’ve made enough progress to feel really good about it.
I suspect it’s not really the exact system that matters. The important part is I’ve found a system that fits how I work, my attention span, allows me to balance the fun stuff (graphics and coding) with maintenance and testing.
Handling open-ended tasks
Sometimes, a task goes into the system that turns out to be a minor career.
For example, about a week ago, I needed to run rake db:migrate to synch up my data model with the MySQL database for a little Ruby on Rails project.
4 hours later, this has turned into figuring out which of 4 possible combinations of MySQL are installed on the Macbook. Not fun. This task still isn’t factored properly. When it is, there will be a blog post somewhere on how to figure out which of 4 MySQL installations one needs for which purpose.
{ 5 comments }








