Time Tracking In 2020

As 2019 was wrapping up I found myself wanting to get some kind of high-level picture of what I’ve spent the year doing. First, I’m just curious. Second, I want to know how much time I’ve spent building out different engine systems and if that time matches my initial estimates. Third, I want to make sure that I’ve spent my time doing “the right” things.

I think all good programmers have something of an obsessive nature and it’s sometimes easy to get carried away with refactors and optimizations that in the big picture maybe don’t matter that much. With the small team we have at The Machinery, working on building a complete engine that outshines the competition, we can’t afford to mess around. I’m usually pretty good at staying focused, but I’m always striving to improve.

I also want to get better at making time estimates. This is a notoriously difficult thing that we programmers get asked to do all the time by our managers. Often we balk and try to squirm away: “That’s impossible! I can’t possibly know how much time it takes before I’ve done it!”

It’s easy to scoff at this attitude, but I actually think it is pretty reasonable. Estimating how long it takes to code something is hard because programming is fundamentally different from most other human endeavors. If you are building bridges, doing woodworking or cleaning the house, you typically have a relatively short planning phase where you decide what to do and then a long execution phase where you hunker down and do it. In the planning phase, you can make a reasonable estimate of how long this execution phase is going to take.

However, programming, at least the way I see it, is pretty much all planning. The bulk of programming is deciding how to solve something: what the APIs should be, how different components should work together, etc. When you have decided exactly what do, writing out the code is trivial. (For this reason, I also don’t really like splitting coding into a planning and a coding phase. In my view, coding is planning.) Since planning is the bulk of the work, estimating the size of a coding task means trying to plan how long the planning is going to take. At that level of meta-analysis, things become pretty sketchy. Many programmers don’t want to give management numbers they’re not sure about, out of (an often valid) fear that management will take those numbers and run with them.

But since I’m an owner and a founder at Our Machinery, I’m the one asking myself for these estimates. And I’m not willing to let me get away that easily!

As a planning instrument, time estimates are crucial. We want to know how much time something will take to implement so that we can make an appropriate cost-benefit analysis. We also want to be able to present some kind of road map of upcoming features, both for our own sake and the sake of our customers. So we need to tackle the unpleasant task of making estimates.

The first step to getting better estimates is getting time tracking right. If we’re not even sure how long something did take, how can we ever know how long something is going to take. With time tracking as calibration, we can hopefully learn to improve our estimates, even if it’s always going to be a difficult task. For example, I’ve noticed that I often overestimate the time it takes to complete small tasks and underestimate the time it takes to complete big tasks. The reason, I think, is that it always seems reasonable to say that something will take 1–2 days, even though many small tasks can be completed in hours. Whereas for big tasks, it is just hard to think of everything that goes into them. I end up missing stuff and underestimating.

One other thing I think is important is that you don’t punish or reward employees for their estimates. For example, you shouldn’t force people to work overtime because they underestimated or praise them because they overestimated and are “done early”. Neither should you shame them for making estimates that are too long: “What, it’ll take you three months to do this?” All of this will just push your employees to make worse estimates.

Enough set about this tricky topic. In the rest of this post, I’ll focus on time tracking.

Looking back at 2019, I found it pretty hard to discern exactly where and how I had spent my time. This even though I actually had three different and pretty detailed records of the work I had been doing:

So the problem is not a lack of data. Rather, the problem is too much data! It’s hard to see the forest for the trees! Going through these logs and trying to summarize them into high-level information like “How long did the physics system take to write?” would mean slogging through thousands of entries.

I suppose I could sit down and sift through all of this, write some script to automatically analyze the logs and the email archives and merge the information from all three sources to get a more complete picture, but that would likely take days. And considering that the whole point of this was to find out how to spend my time more efficiently that does not seem like a prudent thing to do.

So for 2020, I’ve decided that I need to do time tracking differently. If the goal is to have high-level, big picture information available at-a-glance, then that is what I should be collecting all the time — not try to piecemeal together at the end of the year.

I have three main things that I want to accomplish with time tracking.

Given these goals, here’s the system I’ve come up with:

Here’s what the spreadsheet might look like:

It’s not always 100 % clear how to draw the line between Feature and Maintenance work. For example, while I’m working on a feature I often discover that another system needs to be refactored or has bugs. Typically I record that as Feature work. My reasoning behind this is that the refactoring and API changes that need to be made are an integral part of the work on that feature (without the feature, they wouldn’t be needed — YAGNI). Also, discovering and fixing minor bugs is just a natural part of coding.

The only exception is if I discover a particularly hairy bug in another system. Say a bug that takes more than 1–2 hours to fix. In that case, I will record it as Maintenance work instead.

I aim to keep this time tracking system up for the rest of 2020 and see how it works.