Tempus - Rethinking what to Track

Introduction

I am writing an experimental time tracker for software development workflows. It is called Tempus and you can see more information about the motivation behind it in my previous article and the source code on my GitHub.

I have been using the first iteration of Tempus since the 14th of September (nearly a month at time of writing). I am even using it right now as I write this article, as I use it to keep track of how I spend my time on my various side-projects.

In this time I have realised that if I am going to write a time tracker specifically for software development workflows, I cannot write a time tracker which is essentially the same as any of the existing options and state that its for devs simply because I am a software developer myself suffering from Not Invented Here Syndrome. This article is about my thoughts on why one-size-fits-all time trackers aren’t sufficient and how I plan to remedy it in the next iteration of Tempus.

The Issues

I split my Tempus tasks in a fashion similar to the following:

• Slack Chats (meant to refer to IM in general, as I tend to use Skype and Teams too)
• On a Call
• Writing Code
• Thinking Time
• Architecture
• Code Review
• Stand up break
• Debugging
• Dealing with external providers
• …etc

Part of what aids adoption of any system is a well designed User Experience (UX). If the UX is not thoroughly planned for, system’s success tends to be despite of its other characteristics rather than because of them.

This is the reason why public transport adoption is better in some countries over others - if the UX of public transport in Malta sucks (and it does), and the only alternative is to drive your own personal car (even with its accompanying issues with parking and cost), then the adoption of public transport will be low.

Any solution to this that does not address the basic UX issues (timeliness, availability, frequency, reliability, etc) is simply a micro-optimisation to a macro problem.

In using Tempus, I (as a User), eXperienced the following main issues:

1. I often do not know which task to choose. I have a task for being On a Call. I also have a task for Debugging. So if I am debugging a production issue whilst also on a call with a colleague, which one should I choose?
2. Some context is being lost. I could be Debugging in either our development environment (such as: the build was successful on my machine but not in our CI pipeline), or our production environment (such as: diving into incoming logs to diagnose an urgent ongoing issue)
3. I would often forget to switch tasks once I have completed them (I would sometimes remain On a Call for over 15 minutes after the call concluded)
4. I do not have a clear idea of whether I was hitting my ideal time spent ratios. If my current position or the current week calls for a 50:50 split between writing code and working on our architecture, the only way I could reliably know that I was reaching that ratio was if the only two tasks I used were Writing Code and Architecture. Since there were other tasks interleaved with missing context (such as On a Call, which may have been either writing code or architecture), I could not reliably track my progress.

The Solutions

Issues 1 & 2 - Choosing between tasks & lost context

The idea so far to solve these issues is to double down on characteristics unique to software development workflows. After all, Tempus is meant to be a niche tool so I should design and develop it with that aim in mind.

Instead of tracking tasks I suppose that tracking the mode that the task is being performed with. The UI look something like this, where each option is a button. Choosing any option would deselect the other option in the row (behaviour similar to radio buttons).

In the initial idea of Tempus I thought about supporting concurrent tasks, in an effort to support a structure similar to the above, however I decided against it in the interest of simplicity. The difference between free-text concurrent tasks and the above is that one would have to define each mode and the possible values of that mode. It would also make sense to somehow link the values of different modes together via simple rules - for example if I set myself to AFK, then Tempus could remove the selected value for the Task, Communication and Environment modes, whilst retaining the values for Workplace.

Issue 3 - Forgetting to switch tasks

This issue is not particularly addressed by the redesign and would be better addressed by the introduction of some sort of hook mechanism - one such as “if I stand up from my seat, hit the Tempus API to switch my Physical mode to the standing value”.

In the mean time, I would add functionality to change the start and end time that a specific mode’s value was active - for retro-active repair of incorrect data.

Issue 4 - Reliably tracking my progress

The current version shows me a very basic breakdown of how much time I spend on what task. I setup a very basic chart component which literally consists of a div element with a fixed height, max width and then the actual width is set on page render (width: {{ .Task.Percentage }}%).

Here is a screenshot of the breakdown of all my tasks on my production Tempus instance:

To my surprise, 30% of my time is spent solely in some sort of active, synchronous communication. Surprise aside, this only tells me how much (percentage of total) time I spent on a task - it does not tell me whether I am spending either too little or too much time on a specific task type. It would greatly help if I could set daily/weekly targets of, say Not more than 40% of my time should be writing code, to avoid getting stuck trying to optimise my code too much instead of sticking to good enough, alongisde at least 20% of my time should be standing up, to help combat the health issues that come with a sedentary style of work and too much sitting down, encouraging me to make use of my standing desk more.

Conclusion

In conclusion, it looks like the Tempus project is already bearing fruit - helping me flex my UX Design muscles alongside my effort to learn more Go, as also outlined in my previous article about learning to write a real-time game from scratch.