Software developers never want to do hourly time tracking.
I’ve seen team leads who fill out the time tracking for their whole team to spare them the trouble. I’ve seen developers agonize over what to write down: they feel like they’re estimating even when it should be a simple matter of hours.
Why is it so much trouble?
Hourly time tracking is difficult because there are no hour-long chunks. You can’t write them down because they don’t exist.
Let’s look at why that is.
How Programmers Work
A lot has been written about the cost of interruptions and the maker’s schedule. Programmers are effective when they can get in the zone (AKA flow) and it takes time to do that. I’ve heard this time cited as being 15, 30, or 60 minutes. It probably depends on the developer and the task at hand. If a programmer is in the zone and they get interrupted then they have to redo this upstart time. This also means you should only work on one project at a time because it applies to switching tasks just as it applies to interruptions.
Let’s say you’re working from 1 to 5 in the afternoon–a solid 4-hour chunk. You spend the first hour working but you aren’t really productive until you get in the zone at 2pm. You spend 2 hours being superhumanly productive, then at 4pm you go and get coffee and can’t get back in the zone again. It feels wrong to say “I worked for 4 hours”. You only feel like you “worked” during the time you were super productive. But it feels equally wrong to say “I worked for 2 hours.” That 2 hours of superhuman productivity wouldn’t have been possible if you just worked those 2 hours in isolation.
It seems like the atomic unit of work for a programmer is “times gotten in the zone.” However, you can’t schedule your time around that. “Hey, I’m going to just get in the zone real quick for a few hours then head home.” Nope, you don’t have that much control over it. Some mornings you will be having a rough day and you can’t get in the zone. Some afternoons you’re so in the zone that you suddenly realize everybody went home and you’re late for dinner.
Incubating
It gets even more complicated than that. Many programmers spend a lot of time incubating. Incubating is when you seem to be doing some other activity, but you’re subconsciously processing an important problem. Have you ever been stuck on a hard problem, then gone and browsed photos of cats for awhile, then afterward you just magically knew the answer? That’s incubating. I can’t tell you how many times I was stuck on a problem, gave up and went home, then woke up in the morning with the problem solved in my head. Apparently rats do this too. To say I worked an 8 hour day on a programming project is never accurate. Nor is it accurate to say I spent 24 hours on a programming project. Some of my work was active, some of it was passive, and some of it was subconscious.
What it looks like
A naive graph of programming effort over a week might look like this:
If you take “the zone” and “incubating” into account, it might look more like this:
This is a completely made-up graph, but it feels right for me. It’s quite different from person to person, week to week. For some people maybe it does look like that first graph, but not for anyone I know. You might also notice that the “Real” graph adds up to be more total work than the “Naive” graph. That’s because someone who sits at a desk for 8 hours a day 5 days a week does more than 40 hours of work. That’s just how it is.
Days and Weeks
So you can’t divide programming time into hours. Days are better, but it’s still a little fuzzy. Notice that in the second graph the effort only went down to 0 during the weekend. Maybe that’s idealistic, but I sincerely try not to think about work over the weekend. This makes weekends the best place to divide segments of work. Further, weekends are a good time to switch projects: if I stop working on one project on Friday and start a new project on Monday it doesn’t feel so bad. I have to do the Monday morning “getting back in the groove” either way.
This is why at Bocoup our team members only work on one project at a time and the length of a project is measured in weeks. We believe that hourly or even daily accounting of time for programming tasks is not realistic and gets in the way of both productivity and happiness. This does require that we have a lot of trust in our team, which is a really good thing to have for a million other reasons too. In the past we’ve turned down work that required hourly time accounting for this reason. This hasn’t ended up being much of an issue because the industry has been gradually getting more realistic about how programmers work. That means happier programmers and better software.
