The Power of Time Tracking

A day or a week I have no recollection of feels like a lost part of my life. Travelling, birthdays and weddings tend to stay with us. The ordinary days are harder to hold onto: we work, answer emails, have dinner and go to bed. There may be something worthwhile in those hours, but looking back, it can be difficult to say what.

This is what interests me about time tracking. I don’t see it as another productivity ‘hack’, another way to squeeze more juice out of your work. I’m interested in what a small, deliberate record of our days can help us remember—and what we might learn from returning to it.

Beyond the timesheet

We usually encounter time tracking through work. Freelancers and consultants allocate hours to client projects; employees fill out timesheets so their work can be billed to the right financial ‘buckets’. These systems answer a practical question: how much time went into this job?

I believe there is value in extending that question into our daily lives. Which kinds of creative work leave us feeling fulfilled? When do we find room for them? Are the things we say matter to us actually getting our attention?

Recording our activities makes an otherwise vague day concrete. An hour and a half spent scrolling on our phone sits alongside an hour-long walk with our significant other. A half-hour spent drawing on the train, easily lost in the haze of a busy day, becomes something we can return to. Which of these moments brought us joy, and why? Which would we like to make more room for?

The duration alone cannot answer those questions. Thirty minutes of drawing is a record of time spent, not a measurement of how rewarding it felt. But the entry gives us somewhere to begin reflecting. Over weeks and months, these small records can reveal patterns that memory alone would struggle to preserve.

Tracking will not make every day memorable, or prevent stretches of life from feeling repetitive. I see it as a modest way to revisit our days before they disappear into one another. The value comes from the combination of a record and the attention we give it.

That purpose has consequences for the design of the tool. A tracker built to calculate billable hours will look different from one built to understand creative rhythms. Before deciding what to record, we need to ask what we hope to learn.

Examples

Rather than prescribe a single method, I want to look at five trackers built by people for their own use. Each made a different set of choices about what mattered, what to measure and how much effort a log should take. The versions discussed here are the ones that informed this essay; the screenshots and descriptions are a study of their design, rather than a guide to their current features.

Horaire: the character of the work

Horaire, by Linvega, recorded a daily log using three values:

• Sector (Sh): the general type of work—Audio, Visual or Research.
• Concrete Hour (Ch): an index of concrete output, from inward-facing tasks such as documentation and planning to outward-facing tasks such as releasing a project or giving a talk.
• Focus Hour (Fh): an index of how much of the available time was invested in the task.

Despite their names, Concrete Hours and Focus Hours were indices, not elapsed hours. Both used a scale from 1 to 9. Dividing Ch by Fh produced a value Linvega called General Productivity (Ph). The documentation explicitly described this as ‘not seen as a net positive’: a larger number was not necessarily better.

Two examples make that distinction clear:

A focused day of planning produces a lower value than a performance with less of the available time invested. Judged as a conventional productivity score, that seems counterintuitive. But Horaire’s measure describes the character of the work: time spent preparing and reflecting, compared with work that faces an audience. A project may move between these modes as it develops, reaches release and enters maintenance.

I find this an interesting example precisely because the metric is unusual. Instead of treating productivity as output per hour, the system encodes a particular way of thinking about creative work.

Horaire also compressed several decisions into a short code. In 238, the first digit identified Visual work, the second identified the storyboard task, and the third recorded a Focus Hour value of 8. The task code carried both a name and a position on the inward-to-outward scale. There was no need to type each piece of information separately.

This numeric organisation reminds me of Johnny.Decimal, a system for organising information. What interests me here is the amount of meaning a small identifier can carry once its structure is established. I’ll return to that idea under data compression.

Chronologicon: when the work happens

Chronologicon, by Craze, used a command-line interface built with Python. Each work session was recorded by starting and stopping a timer, rather than making a daily assessment.

A session had a discipline, such as visual, code or research; a project; and an optional note describing the task. The commands were straightforward:

chron start 'discipline' 'project' 'note'
chron stop

Logs were saved in logs.json, and chron stats displayed a dashboard:

The important choice here is to retain start and end times, rather than duration alone. Knowing that you spent two hours on a project tells you something about its demands. Knowing when those hours happened also lets you examine how the work fits into your day.

That distinction opens up different questions. Do you regularly find time for creative work in the morning, or does it happen late at night? Are some disciplines concentrated in particular hours? A dashboard like this can show when work was logged, though it cannot tell us from duration alone when our best work was done.

Færeld: choosing how to look back

Færeld, by Naylor, was another Python command-line tool. Here, entries were made by supplying start and end times manually.

Each entry belonged to an area. Research, design, development, documentation and testing were tied to projects. Other areas—reading, languages and real-life engagements—used a task or subject instead. This distinction leaves room for activities that matter without requiring them to belong to a formal project.

The timestamp format was Day Short-Month Year // 24H.M; for example, 03 Dec 2017 // 17.00. Entering both endpoints preserves the same kind of time-of-day information as a timer, but does not require you to start the tool before beginning the activity.

Færeld offered three ways to review the record: summary, projects and productivity. These views showed an overview of the logs, time spent on individual projects, and time logged by hour or day of the week. The screenshot below shows its summary mode:

I like the appearance of this visualisation, but I’m less convinced by the clarity of the session-duration box plots. The totals above them have explicit hour-and-minute labels; the plots have overall minimum and maximum values but no graduated time axis. I can compare the shapes, yet reading a duration from an individual plot is difficult.

This is a useful distinction when designing a dashboard. A visualisation can reveal a broad pattern without giving a precise value, and sometimes that is enough. But it should be clear what the reader is meant to learn from it. Looking impressive is not, on its own, a reason to include a chart.

Avanier’s Log: beginning with an intention

Avanier developed Log into a desktop app before simplifying it into a command-line tool integrated with his wiki. A session began with a sector, project and task description.

The detail that interests me most is what happened around the timer. Avanier began by entering what he intended to do. When the session ended, completion was graded with a binary score: 1 for a completed task, 0 for an incomplete one. Multitasking was discouraged by design.

This changes the act of logging. An entry made afterwards asks what happened; an entry made before the work begins also asks what you intend to happen. The completion score then gives you a reason to compare the two. A timer can otherwise become a record of what you were supposed to be working on, rather than what you actually did.

One of the older desktop dashboards also showed average session duration:

Knowing both your available time and the shape of your sessions can help you plan more realistically. If you average eight hours of personal project work each week, you have a better starting point than the vague intention to work on something ‘from time to time’. But eight hours spread across short sessions is not the same as four uninterrupted two-hour blocks. The record can help you see which kind of time you actually have.

Ivanov’s Log: where the time goes

Ivanov’s Log took a more detailed approach. The version considered here read plain-text entries and visualised them using PHP. Each log contained a date, duration, project, task, division and details:

DATE        TIME  PROJECT  TASK         DIVISION  DETAILS
2017.08.30  1.0   V-OS     Development  Visual    Testing headers.

Duration was recorded in half-hour increments. The division described a broad type of work—Abstract, Audio, Code, Personal or Visual—while the task gave a more specific category. Project and task were separate, allowing the same activity to be understood both as a kind of work and as a contribution to a particular project.

Ivanov also used four ‘Arch Projects’—Doodle, Tinker, Jam and Study—to accommodate work that did not belong to a named project. I like that this gave exploratory work a place in the system without pretending it had a defined deliverable.

The dashboard showed total hours and relative percentages, alongside a long-term timeline and shorter views of recent activity. It made the distribution of time visible at several scales: between types of work, across tasks and over successive days.

Compare this with Horaire. One system describes how time is allocated; the other builds a personal index of the character of the work. Neither is a universal measure of a well-spent day. They are different answers to different questions.

Design Principles

These examples are useful because they expose decisions that are easy to overlook. Recording a timestamp, asking for a completion score or requiring a project name may seem like a small detail. Each changes what you can learn—and what the tool asks of you.

Insight

The first question should be: what do I want to learn about my life?

Start there, rather than with a list of fields or a dashboard you would like to build. If you want to understand when you make time for creative work, you need dates and start and end times. If you want to know how your attention is divided between projects, dates, durations and project names may be enough. If you want to explore the relationship between time spent writing and progress made, you could record duration alongside words written.

The question need not be about work. You might be interested in the time spent watching films, split by genre, or in how often you make room for a particular hobby. What matters is that you can explain why the record would be useful to you.

It is also worth being precise about what a metric can tell you. Hours logged are not automatically hours of focused work. A completed task does not necessarily make a session fulfilling. If fulfilment is what you are interested in, the totals need to be read alongside your own reflection; they cannot stand in for it.

This is why I’m drawn to personal systems rather than commercial tools such as Toggl Track. A tool built around client work and billing may do its job very well while leaving my questions unanswered. I believe there is real value in designing a system from your own priorities, rather than adopting someone else’s definition of productivity.

Building your own software does require time and technical ability. If that is not something you want to take on, Timewarrior is an open-source command-line option worth considering. I would still begin with the design questions, then read the documentation to see whether the tool fits. Choosing software should follow from deciding what matters.

Friction

Every additional field offers another possible dimension of analysis. It also asks for more effort, every time you make an entry. Possible is the important word: data you never use is still work you have to do.

Record no more than you need to answer your question. A date lets you compare days and weeks; start and end times let you examine patterns within a day. A completion score is useful if you want to examine whether you finish what you intend to do, but it has no reason to be there otherwise.

Low friction makes a system easier to keep using. If an entry takes too much effort, it becomes tempting to postpone it, estimate yesterday’s work or assign a large block of time to what you were supposed to be doing. The apparent detail of the record then hides uncertainty in the inputs.

In my experience with these tools, catching up can become enough of a hassle that the system is abandoned. A quick log, made consistently, is more useful than an elaborate one that gradually falls out of use. That does not mean the shortest possible entry is always best; it means the extra detail needs to earn the effort it takes to record it.

Category Hierarchy

Many of these trackers organised entries at three levels:

• Type of activity: Sector, Discipline or Division.
  • Category or project: what kind of task it is, or what it contributes to.
    • Description: the specific thing you did.

The first level depends on the life you are trying to describe. Coding, design, research and writing suit some kinds of creative work. Other useful distinctions might be professional and personal, consuming and producing, or films, music and television. These are choices about what you want to notice, not categories everyone needs to adopt.

At the second level, consider whether you care more about the activity or the project. ‘Typography’ tells you the kind of work; ‘Website’ tells you where that work belongs. Recording both, as Ivanov did, allows different comparisons, but also adds friction. I would start with one unless I had a clear use for both. For activities without a defined project, something like the Arch Projects can provide a home.

A description adds the finest level of detail. It can make an entry more useful to return to, or help explain what went into a particular deliverable. It is also another thing to type. Keep it if that context matters; don’t require it simply because other trackers have a notes field.

Data Compression

There are two ways to make a log shorter: record less information, or find a shorter way to express the same information. These are different decisions.

Consider three entries in a .csv file:

AREA,CATEGORY,DESCRIPTION,DURATION
Design,Typography,Modify h3 size,2.5
Writing,Journal,Daily notes,1.0
Coding,JS,Fix array function,1.5

If the area and category are combined into a two-digit ID, they can be entered more quickly. Suppose 22 means Design / Typography, 13 means Writing / Journal and 35 means Coding / JS. The first digit identifies the area and the second identifies the category within it, much as Horaire embeds meaning in its task codes.

If the descriptions are not needed, the entries can be reduced to:

ID,DURATION
22,2.5
13,1.0
35,1.5

The IDs preserve the area and category, provided their meanings are kept in a stable reference. Removing the descriptions, however, discards information: we can no longer tell which typography change or JavaScript fix the entry refers to. Shorthand reduces the effort of entering data; omission reduces what the record can tell us.

For someone making many entries each day, a compact code may make the difference between keeping the habit and abandoning it. For someone working in long sessions, the cost of adding context may be small enough to be worthwhile. The aim is to reduce repeated effort without losing the distinctions you care about.

Timer vs Manual Input

A timer asks you to begin an entry before the activity. Manual input asks you to reconstruct it afterwards. Both have advantages, and both can produce misleading records.

A timer captures start and end times without relying on your memory, and can be paused when you are interrupted. As Avanier’s Log demonstrates, defining the task before you begin can also give the session a clear intention. But a timer left running while your attention is elsewhere will still count that time.

Manual input allows you to record an activity without interrupting it to operate a tool. You might enter its start and end times, as in Færeld, or estimate a duration, as in Ivanov’s Log. This can produce a simpler record, but relies on your ability to recall the work and account for distractions.

A related choice is time resolution: how finely you divide the day. A timer can record every short interruption; a manual log can round a session to the nearest half-hour. Greater precision is not automatically more useful. If you are trying to understand how your week is divided between creative pursuits, half-hour estimates may serve you well. If you want to examine the length of uninterrupted sessions, those estimates would hide the thing you are trying to see.

These choices affect the experience of the work as well as the record. I would be wary of a system that demanded more attention than the activity it was meant to help me understand.

Returning to the record

A time tracker only becomes useful when we return to what we have recorded. At the end of a week, we can compare the days we remember clearly with the ones that have already blurred. What did we make time for? What kept being deferred? Was there a small creative window we would otherwise have overlooked?

This is where the design choices begin to prove themselves. If a field never helps you answer a question, consider removing it. If you repeatedly wish you had recorded a particular detail, consider adding it. A prototype used in ordinary life will teach you more about those trade-offs than a perfectly specified system you have not yet tried.

There is room to take this further: more elaborate visualisations, or comparisons with sleep, stress and exercise. I don’t feel qualified to prescribe those approaches, and I would be reluctant to add that complexity before the basic habit had proved useful. A system that remains simple enough to use over the long term gives you a better basis for deciding what to explore next.

What draws me to time tracking is the possibility of keeping a little more of ordinary life within reach. I want a record that helps me remember what I did, understand what mattered and make room for more of it. The numbers are useful only insofar as they help me do that.