Why does switching tasks break a time tracker?

A stopwatch needs a task to hold still long enough to be measured. Real work almost never does. You are two paragraphs into a report when a colleague messages you, you answer, you come back, the phone rings while you're mid-sentence, you take it standing in the hallway, and twenty minutes later you're back finishing the paragraph you started before any of that happened. A tracker built around one clean block of one activity was designed for a kind of day that most days simply are not.

A tracker assumes the day comes in blocks

The mechanics of a stopwatch-based tool are simple on purpose: pick what you're about to do, press start, work until you stop, and what's left over is a number. That number is only honest if the block it measured was actually one continuous thing. The whole design leans on an assumption that a task will hold its shape for the length of time it takes to finish — that "write the report" stays "write the report" from start to stop, without anything else happening in between.

Most work does not hold its shape like that, and most days interrupt themselves constantly and for good reasons. A colleague needs an answer now, not in an hour. A child needs something. A call that was scheduled weeks ago lands in the middle of something else entirely. None of this is a discipline problem. It's just what a normal day looks like once you stop assuming it will behave like a lab experiment.

What switching actually does to the numbers

Every interruption forces a small decision a stopwatch was never built to make gracefully: stop the current timer, or let it keep running while you do something else under its name. Stop it, and now there are two entries instead of one, plus a second start you have to remember to make when you return. Let it run, and the number quietly stops meaning what it claims to mean — it now includes ten minutes of a phone call that had nothing to do with the report.

Do this five or six times in an afternoon and the tracked total is no longer a record of the work. It's a record of how carefully you managed the tracking tool while the work kept getting interrupted, which is a different and much less interesting number. The report might have taken ninety honest minutes of attention spread across three hours — the timer has no way to say that, only a total that is either inflated, fragmented into a dozen tiny entries, or quietly wrong.

The busiest days are the ones that switch the most

This is why time trackers tend to feel heaviest on exactly the days they'd be most worth having. A slow, single-threaded afternoon is easy to track well because there's nothing much competing for the timer's attention. A day stitched together out of messages, calls, and half-finished threads is the opposite: every switch is another moment where you have to stop and manage the tool instead of the thing you're actually doing. The tool asks for more precisely when there is less room to give it.

A written line doesn't need the day to hold still

A log entry has no block to protect. There is nothing running that an interruption can corrupt, because nothing was ever started. You can write "answered a call about the invoice, then finished the report" as one line, whenever it's convenient, and it is simply true — not a compromise, not a workaround for a tool that couldn't keep up. The switching isn't a problem to be managed; it's just what happened, and a line of text is perfectly capable of saying so.

This is also why a log tends to survive exactly the days a tracker gives up on. It never asked the day to behave in the first place, so there's nothing for a chaotic afternoon to break.

What this is actually telling you

It's tempting to read a fragmented, hard-to-track day as a personal failure — too scattered, too unfocused, bad at managing time. Usually it isn't that. It's a mismatch between the shape of the day and the shape the tool needed the day to have. A day made of many short, real things is not a worse day than a day made of one long thing. It's just a day that a stopwatch was never going to describe well, no matter how carefully you used it.

TimeMap doesn't ask a task to hold still. There's no clock running that an interruption can throw off, and no block to keep clean — you write a line about whatever you were actually doing, whenever you get to it, and a switch between three things in an hour is just three lines, not a problem to solve. A day that felt scattered while you lived it can still read back as a perfectly coherent record afterward, because the record was never depending on the day holding a single shape to begin with.