After breakfast, hopefully 7:15am, I make a list of things I want to carry out on that day. I write this list by hand on a notepad to always keep it in front of me. This includes some tasks that might not have to do with work. I estimate how long each of these will take, so I know at the start of the day what can I realistically accomplish. Anything that I haven’t done and it’s important, I move it to the next day, or I add a reminder in my calendar. Anything that I haven’t done and is not overly important is left behind.
Task estimations allows me to say – “There’s a meeting in 15 minutes. Let’s pick a 10 minutes task and do it.” This helps me to avoid the paradox of choice. Without estimations, I would have hesitated for 5 minutes, picked one task, and most likely run late to the meeting so I could finish it. They also allow me to know beforehand how busy will my day be, and how much spare time will I get.
Aside from daily Japanese study, which I do every single day, I mark three tasks with a black line, meaning these are the 3 priorities for the day. Almost invariably, code reviews are one of them. I start the day off by doing around 30-40 minutes of email, but I don’t count it as part of the 3 priorities. I use offlineimap and mutt for that, and unless necessary, I don’t check email for the rest of the day. After lunch I might refresh to see if anyone needs something urgently, but that’s it.
I work in chunks of about 50 minutes, taking breaks of 5 minutes which I spend cleaning, reviewing kanji, playing with the cat, or just not sitting. Working for more than 1 hour will usually result on a longer break. I use workrave to keep track of this, and it works like a charm. Even if I’m not working, I still work in this fashion as I know I have a tendency to get RSI or tendinitis.
The way I choose what tasks to put on the list -work related- is defined by a pyramid I made. Top means most important, bottom means least important.
- level 1 – Security bugs, CVEs
- level 2 – Release blockers (upstream or downstream)
- level 3 – Learning opportunities. Feature team work
- level 4 – Features that will bring new users. Important bug fixes
- level 5 – Features that might bring new users. Minor bug fixes
If it isn’t clear from the priorities ‘pyramid’ I’m mostly focused on getting more people to our projects, and delivering timely, stable releases. That doesn’t mean I let minor bugs ‘starve’ on the queue, but it’s unlikely they would be solved by me if there is a release soon and other issues are blocking it. As any human, there are times where I simply don’t have the energy to properly work or review on level 1,2,3 items, and I resort to simpler issues as a way to clear my mind and get something done.
Since I work on an open source project, reviewing contributions is also part of my work at Red Hat. It is not a minor part of my job, in fact I probably spend 1/3rd of my working hours doing that. I apply the same priorities as I listed above. However, I have not yet found a way to deal with IRC support and Redmine emails. For the former, I normally do it when I’m working on something that does not require my full attention, or if I see someone asking questions about topics I know few people are familiar with. I would love to find a way to process Redmine emails more efficiently, I used to only check closed issues, and change the release tag if needed, but it was very time consuming and I would miss support tickets and not learn about feature requests and bugs.
Any suggestions, criticisms or comments would be highly appreciated.
[1] Some people asked me why would I not use some TO DO app to keep it in sync with my phone. The reason is simple, I want to always keep that list in mind when I’m in work mode and I don’t want to look at it when I’m not. I do use Evernote to keep track of yearly goals I set through a weekly system.
This is roughly a repost of an internal newsletter I run at Red Hat.
Thanks to Edmond Lau, whose book The Effective Engineer helped me to design this system.
Neat. I’m not nearly as organized as you for picking what I work on in a day, I wish I was.
For Redmine/Bugzilla though I have a workflow I’m happy with. It all centers around my mail filters , which I have about ~30 of. And mutt shortcuts. I wish I could export them to share on GitHub, but alas Zimbra does not allow that.
For Redmine, it all goes to a redmine folder, but important mail gets flagged
* These are where my user is in X-Redmine-Issue-Author and X-Redmine-Issue-Assignee
* Keywords I’m interested in are in the subject – Salt, FreeIPA, templates, etc.
I have similar rules for bugzilla, although needinfo flags go to inbox so I see it right away. Also, all bugzilla updates from pm-rhel@redhat.com go straight to trash.
In the morning and after lunch, I usually look at those two folders, but I press my mutt shortcut “i” to only view flagged mail. Everything else I consider noise and I only check once or twice a week.
I keep mutt and irssi open on my second display most of the time, and irssi highlights for topics I’m interested in (same as redmine, mostly), which is how I deal with IRC support.
Great post Daniel! That’s a pretty helpful daily tasks’ program. I kind of follow the same pattern with some minor differences. For instance i normally prepare, write down the next day’s tasks, not in the morning, but the night before, in order to avoid “blind sleeping”. In addition something i find really important and definitely a productivity booster, is applying the Parkinson’s law for heavier/demanding tasks. According to the law “work expands to fill the time available for its completion”. That way, if i think a task would normally take x-time i finally give it half of it.