In pure clock time I work about fifty hours a week. Fourty hour weeks I think are overrated. I wouldn't complain if my manager made me leave two hours earlier each day, mind you, but I think a particular number of hours at work is much less important than the amount of time a person is being productive.
A few years ago I was very frustrated because I never seemed to get done everything I thought I should have gotten done in a week, so I started keeping track of my time. I purposely stayed very low tech and just used a text file with very simple formatting:
dd MMM 2004 7.45a - Admin - Check email on the way in. 7.50a - ContinuingEducationReading - Read blogs on the way in. 8.15a - Admin - Check email. 8.50a - StoryDoing - |Do Implement <Feature Test OM>| Move helpers from unit test into OM itself. 9.20a - StoryHelping - |Help Discuss| Talk with <someone on my team> re: <something in the Test OM>. 9.50a - StoryFixedishCost - |Technical 1:1| <someone on my team>. 11.15a - StoryDoing |Do <Feature> Manual Testing|. 11.20a - StoryFixedishCost - |Meeting Dev| <Dev Tech Lead> 1:1. 11.30a - ContinuingEducationReading - [Reading during] Lunch. 12.00p - StoryDoing - |Do <Feature> Matrix Gen|. 12.10p - StoryHelping - |Help Explain| Tell <someone on my team> why <something in our automation stack is that way>. 12.20p - StoryDoing - |Do <Feature> Manual Testing|. 1.20p - StoryHelping - |Help Discuss| Talk with <someone on my team> re: <something in our automation stack>. 1.50p - StoryDoing - |Do <Feature> Manual Testing|. 1.55p - StoryFixedishCost - |Meeting <Feature>| <Feature team> synch meeting. 2.40p - StoryDoing - |Do <Feature> Manual Testing|. 3.00p - StoryFixedishCost - |Technical 1:1| <someone on my team>. 3.30p - StoryHelping - |Help Explain| Talk with <someone on my team> re: <something in our Test OM>. 3.45p - StoryDoing - |Do <Feature> Matrix Gen|. 3.50p - StoryFixedishCost - |Meeting Intra| <A DevDiv working group>. 5.15p - Admin - Check email. 5.25p - StoryDoing - |Do <Feature> Matrix Gen|. 5.50p - Admin - Check email. 5.55p - ContinuingEducationReading - Read blogs on the way home. 6.00p - StoryDoing - |Do <Automation Stack> User Scenarios|. 6.45p - Home.
When I first started keeping track of my time my scheme was even simpler: just the start time and a description of what I did. This helped me understand how I spent my week, but it was still hard to get a big picture of what exactly I did. For example:
So I started recording a category between the time and the description. That helped with the big picture, but I also need to update my schedule with how much time I spent on each task. So I added a task title between the category and the description. To make it easy to parse this information out of my time log, I set off the category and task title with special characters, giving me this general layout:
<start time> - <category> - |<task title>| description
I have a small C# console app that parses the log and analyzes the data (slightly edited for clarity and to avoid mentioning things I shouldn't, so the numbers may not quite add up):
Community 2:20Do <Automation Stack> User Scenarios 0:40 Do Design <Feature> Test OM 1:10 Do <Automation Stack> 0:05 Do Implement <Feature> Test OM 7:35 Do Pairwise Matrix Generator 0:05 Do Stub <Feature> OM 1:45 Help Code Review 0:25 Help Discuss 8:45 Help Explain 1:40 Meeting <Feature> 0:50 Meeting Intra 1:35 Meeting Test 2:55
Admin #### 16% 1:33 ContinuingEducationDoing # 2% 0:14 ContinuingEducationReading ### 12% 1:11 Hardware # 2% 0:11 Networking # 0% 0:00 StoryDoing ######## 32% 3:04 StoryFixedishCost ##### 23% 2:10 StoryHelping ### 12% 1:11
9h:39m per day, on average
Admin ## 11% 0:52 ContinuingEducationReading ### 14% 1:07 Hardware # 2% 0:10 StoryDoing ####### 28% 2:16 StoryFixedishCost #### 19% 1:34 StoryHelping ###### 27% 2:10
8h:09m per day, on average
The first table totals the time I spent on each task this week. The next table is the average time per category per day since I started recording data this way, and the last table is the average time per category per day for the last five days. (Hmm...much less than usual this particular week. I took an afternoon or two off that week, I think. I don't do anything special to handle time off.)
Now I have data I can act on, rather than vague feelings that I'm not getting enough done. Now I know, for example, that some weeks I get less than two hours a day done on "me" tasks, but other weeks I manage to put in five-and-a-half hours on those tasks each day. I know that I spend an average of an hour-and-a-half on email and other admin tasks each day (e.g., checking email, 1:1s with management) and another two-and-a-half hours in recurring meetings and other tasks of semi-fixed length.
[---Meetings. Yes, I spend lots of time in meetings. I knew when I took this position that part of the job was synching up with other teams in my product group and across Microsoft -- in other words, in meetings. My regularly scheduled meetings include:
With this data in hand I could start to understand where my time was really going and what I needed to change in order to make it go where I wanted it to go. My goal is to regularly spend twenty-five hours each week on me tasks (the StoryDoing category and Do tasks in the tables above), which number I chose because it seems to be the average amount of work various pundits say an average developer gets done in an average week. (And because two hours a day clearly wasn't sufficient. <g/>)
Looking through my log, I could see that I spent a lot of time in meetings (which I well knew) but also that the meetings tended to be spread out throughout the day. Looking at what I did in between meetings, I saw that I didn't often get real work done in that interval. I also realized that I didn't really need to go to all of these meetings all the time. So I moved what meetings I could into blocks of back-to-back meetings, and I converted other meetings into conversations via other means (an email or a short phone call is often sufficient) or just plain skipped them (many of them some of the time but none of them all of the time). The most important change, however, was becoming very disciplined about actually doing work in that 'tween-meeting time.
Of course, before you can get something done you need to know what it is you are to be doing. Even just five minutes is sufficient to make a bit of progress on a spec or user scenario or test case, but only if you don't spend the first four minutes deciding what to work on. I've tried a plethora of different methods for keeping track of and ordering my tasks: a list that I update and copy to a new yellow stickie each week, appointments in Outlook, a list on the front page of my OneNote notebook, and stories akin to what agilists and Extreme Programmers use, just to name a few. I've tried prioritizing and doing the most important task first, timeboxing, living by fire drill, and various other organizational methods. None of this worked very well.
My current process is a variant of that propounded by Mark Forster in his book Help Yourself Get Everything Done and Still Have Time to Play:
<Feature> Test OM 90 <Feature> Matrix Gen 90 To Follow Up 45 <Feature> Manual Testing 45 Code Reviews 45 <Automation Stack Piece> 90 <Feature> Test OM 90 <--- <Intrateam> 90 To Follow Up 45 <Feature> Test Cases 90 <--- Process Improvements 90 <--- <Feature> Test OM 90 <--- <Utility> App 90 Whitepapers 90 <--- Code Reviews 45 <--- <Feature> Matrix Gen 90 <--- <Automation Stack Piece> 90 <--- Continuing Ed Doing/Training 90 <--- <Feature> Manual Testing 45 <--- To Follow Up 45 <---
This list of tasks comprises more or less everything I need to do in a week. For each task I've defined the length of time I'll spend on that task. No task is longer than ninety minutes, so some tasks appear in the list multiple times. The arrows on the right mark tasks I haven't done yet. When I get through everything, I put all the arrows back and start again from the top. Everything gets visited at least a little, and the most important tasks get visited a lot.
This system completely relies on me having the discipline to stop working on a task when its time is up. I wrote a tiny WinForms app to do the countdown for me: countdowns from 5, 10, 20, 45, and 90 minutes are just a button-press away, double-clicking the form pauses/resumes the countdown when I'm interrupted, and it makes a nasty noise when time runs out.
It's taken me awhile, but I'm becoming comfortable with this system. It's working, too: the last several weeks I've been Doing about twenty hours a week. That's less than the twenty-five hours that's my goal, but I'm getting there. It's great to go home actually feeling I've accomplished something!
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need testers, and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.