Forkcasting
As clear as a puddle of mud

Time tracking

2021-Nov-20

I track my time -- what of it?

As far as possible, I track all of my work time. Meetings, projects, tickets, Slack, email, filing expense forms. Even my breaks (lunch, snacks, or otherwise) are timed.

What good is time tracking?

I have one big reason and one small reason for timing everything.

First, I need to be able to look back and answer the question: "did I waste my time?"

Second, I want to know how long future work will take.

Time wasting

I need two bits of information to know if I've wasted my time:

  1. How did I spend my time?
  2. Were those activities a waste?

Time tracking answers the first question, but the second needs more explanation.

I use the definition "Anything that doesn't help a customer is waste." If it doesn't help a customer get a better product faster and cheaper then I don't care.

Examples of useful activities:

  1. Working on delivering a feature that customers need.
  2. Getting better so that I can write better features more quickly.
  3. Helping others get better. This is similar to above, but it can be either direct mentoring or process improvements.

If I have work that does not fall into those categories I try to get rid of it. For example, I spend 2 - 4% of my weekly hours on Slack and email (about 1 - 1.5 hrs). To minimise this I turn off Slack, batch my responses, and pre-answer questions. Pre-answering questions means "clear, concise documentation." As far as possible, I make sure knowledge is out of my head.

I can take my "time sheets" to my manager, explain the problem, and ask for help (or their blessing) to fix it.

Caveat emptor: This all assumes I am (part of) the bottleneck. If you are not the bottleneck, then out-pacing the bottleneck is a waste. Don't overload the bottleneck; help them!

Forecasting

I use my historical data for forecasts. If someone asks me "how long will this take?" I can look at other tasks I've done and use that as my base rate. This includes the problems I usually forget, like fighting build and deployment systems. My own tool automatically rolls-up projects, so I can answer based on the individual task (e.g. implement this API) and the project as a whole. I know how many hours I spend on each project [1].

This works because most projects are similar enough to fall into broad classes. Within those classes I use my judgement to work out if it's better or worse than the average and give a better forecast.

This does not define the project end-date because there are other, more influential factors (e.g. reprioritization, holidays, etc). I separately track start and end dates to help forecast delivery dates.

This strategy usually makes my estimates higher than my colleagues, which often means that people ask my why my estimates are so high. Where-ever possible, I back up my statements with data.

How do I do it?

Old Timey!

This takes commands like timey in project:task to start a timer and timey out to clock out. If someone calls me I run timey int and deal with the interruption. When I get back I note the interruption type, e.g. ops:customer-on-fire. Old Timey prints the name of the task I was on and restarts the timer.

I check how I'm doing at lunch time and the end of the day with timey hours. Finally, I tally things up every week using timey weekly-hours. I put this in a spreadsheet to calculate my overall labour effectiveness (OLE).

My OLE is key, because it accounts for vacation days. I can directly compare week-to-week to look for improvements, assignable causes, and so on.

Internally, Old Timey just prints start and end dates in a file. It uses ledger to do the rest of the hard work. You can do the same with an org-mode extension if you're an emacs afficianado (One may already exist...)

Conclusion

Time tracking isn't that common in software engineering, but I think it's worthwhile for most engineers. Use whatever tool works for you.

Don't let the tool become the thing. You can do much the same as I do here with pencil, paper, and 5 minutes at the end of the work day. I use a tool because I'm forgetful.

Use the data to get better and, where possible, get a clearer view of the future.

Footnotes

[1]I don't do this, but I can also work out the return on investment with this data.