I thought I spent most of my day coding. I'm a software engineer. That's the job, right?
So I tracked every working hour for thirty days, expecting the data to confirm my heroic productivity.
It did not. The numbers were a small, humbling slap. And once I saw where my time actually went, I couldn't unsee it. Here's what a month of honest measurement taught me.
I tracked my time for 30 days and found I spent only about a fifth of my day writing code. The rest went to meetings, context-switching, waiting on builds and reviews, communication, and a surprising amount of plain fragmentation. The lesson wasn't "code more." It was that my real bottleneck was uninterrupted focus, and almost nothing in my default day protected it.
My self-image was "a person who codes all day." When someone asked what I did, I pictured hours in the editor, deep in a problem.
The data laughed at me.
I used a simple time tracker and a notes file, logging what I was actually doing in roughly 30-minute blocks. No elaborate system. Just honesty.
Over a month, my time broke down roughly like this. These numbers are mine and illustrative, but the shape will look familiar to a lot of you:
| Activity | Share of my work hours |
|---|---|
| Actually writing code | ~21% |
| Meetings and calls | ~24% |
| Code review (mine and others') | ~12% |
| Reading code / investigating | ~15% |
| Messaging and email | ~14% |
| Waiting (builds, CI, deploys) | ~7% |
| Context-switching / "where was I" | ~7% |
Twenty-one percent. The thing I considered my entire job was a fifth of my day. That number reorganized how I thought about everything.
Here's the part the percentages don't even capture: it wasn't just that coding was a small slice. It's that the slice was shredded.
I almost never got a clean 90-minute block. My coding happened in 20-minute confetti between a standup and a Slack ping and a "quick question." And every time I got pulled out, the cost wasn't 20 minutes lost — it was the 15 minutes afterward spent rebuilding the entire mental model I'd just had.
That "where was I" line in my table? 7% of my whole month spent just reloading my own brain. That's a full half-day every week paid as a tax on interruption.
I didn't have a coding-time problem. I had a focus-fragmentation problem wearing a coding-time costume.
The deep work — the hard, valuable stuff that actually needs my full brain — can only happen in uninterrupted blocks. And I had almost none. My calendar was beautifully optimized to prevent the exact conditions my best work requires. It's a lesson I keep relearning, and one I explore from the time-management side in how I protect two hours of deep work a day.
Twenty-four percent in meetings was bad enough. But the real damage was placement.
A 30-minute meeting at 11am doesn't cost 30 minutes. It poisons the whole 10-to-12 block, because you can't start anything deep when you know you'll be interrupted. You end up doing shallow busywork in the gap, waiting for the meeting, then recovering after it.
I started labeling these in my tracker as "meeting-shadow" time — the focus I lost around meetings, not in them. When I counted that, the true cost of meetings on my deep work nearly doubled.
So I did three things:
Measurement without change is just anxiety with extra steps. Here's what actually shifted based on the data.
I protected mornings ruthlessly. My focus data was clearly best before noon, so I stopped donating that window to email and meetings. The first 90 minutes of my day now go to the single hardest thing, before the world wakes up.
I batched the shallow work. Messaging and email were 14%, but worse, they were constant. I moved to checking them in a few scheduled windows instead of reacting all day. The world did not end. Most "urgent" things weren't.
I reduced waiting. That 7% of build-and-deploy waiting was secretly worse than it looked, because waiting is where I'd drift to Slack and lose the thread. I invested a couple of days in speeding up our local feedback loop with better developer tools and tighter test selection, and clawed back both the wait and the drift it caused.
I stopped multitasking during code review. I'd been reviewing PRs in tiny distracted slivers, doing a bad job slowly. Batching review into a focused block made it faster and better.
I started saying no to fragmenting meetings. Not all of them — but the ones that landed mid-morning and poisoned my best block. I'd offer an async update or a different time. Most people genuinely didn't mind; they just hadn't thought about the cost their 11am slot imposed on the person attending. The data gave me the spine to ask, because I could point at exactly what that placement cost.
One more thing surprised me: the changes compounded. A protected morning meant I finished the hard task earlier, which meant less stress in the afternoon, which meant I wasn't doom-scrolling Slack as a tired escape, which meant the next morning started clearer. Fragmentation has a vicious cycle; focus has a virtuous one. The measurement didn't just show me a number — it showed me which cycle I was feeding, and let me choose the other one on purpose.
The deepest lesson wasn't tactical. It was this: I had been very busy and not very effective, and I'd been mistaking the first for the second.
Busy felt productive. Slack lit up, meetings filled the calendar, I ended each day tired. But the actual high-leverage work — the code, the hard thinking — was getting the scraps. I was spending my best energy on the easiest tasks and my leftover energy on the hardest ones. Learning to spend your sharpest hours on your highest-leverage work is, in my experience, a quiet part of the brutal truth about becoming a senior developer. Research from Harvard Business Review keeps finding the same thing: knowledge workers badly overestimate how productive their fragmented, "busy" days actually are.
Measuring it broke the illusion. You cannot feel your way to this truth. The feeling of busyness actively lies. Only the data tells you that you spent your sharpest two hours answering messages a future version of you could have batched in fifteen minutes.
Busy is a feeling. Effective is a measurement. They are not the same, and most of us are optimizing for the feeling.
Q: What tool did you use to track time? Honestly, almost anything works — a basic time-tracking app plus a plain notes file. The tool matters far less than the honesty. The magic is in writing down what you actually did, not what you meant to do.
Q: Isn't tracking every block exhausting and distracting? A little, for the first few days. But 30-minute granularity is light enough to sustain, and you only need to do it for a month to learn the lesson. Treat it as a temporary experiment, not a forever habit.
Q: Is 21% coding time actually bad? Not necessarily — senior roles involve more communication and design by nature. The point isn't the exact number; it's whether your best hours go to your highest-value work. Mine didn't. That's the problem, not the percentage.
Q: How do I protect focus time if my culture is meeting-heavy? Start small and make it visible. Block one window, tell your team why, and bring your data when someone questions it. "I do my deep work here and my output depends on it" is hard to argue with, especially backed by numbers.
Q: Did productivity automation help? The biggest win was reducing waiting and context-switching — faster local builds, batching shallow tasks, letting automation handle repetitive setup. Anything that protects an unbroken block of focus is worth more than it looks on paper.
I went in trying to prove I was productive. I came out understanding that I'd been mistaking motion for progress for years.
The fix wasn't to code more hours. It was to stop shredding the hours I had, and to spend my sharpest energy on the work that actually needed it.
You can't manage what you won't measure, and you can't feel your way to the truth about your own day. The data knows things your self-image refuses to.
If you try even a single week of honest tracking, you'll likely learn something your self-image has been hiding — and if you want more engineering-life experiments like this, the senior-developer pillar collects them.
Thirty days of honest tracking cost me almost nothing and changed how I structure every week since. If you've never actually measured where your day goes — what do you think you'd find?
I spent years saving the hardest task for when I 'felt ready.' Doing it first instead quietly fixed my focus, my dread, and my output.
I tracked every distraction for a week and was horrified by what I found. Then I fixed the three that mattered most.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!