Where Does Your Time Actually Go? A Developer's Guide to Finding Out

The "I was busy all day but what did I actually do?" problem is close to universal among developers. It's distinct from real overwork (which is a scheduling issue) and distinct from burnout (which is a well-being issue). It's a visibility problem: your day felt productive in the moment because you were constantly doing something, but by 5pm you can't point at what moved.

Most solutions to this problem skip to prescription — "block your calendar," "batch Slack," "do deep work in the morning." The useful first step is much simpler: see where your time is actually going. Not estimate. See.

This post is about setting that up if you're a developer, why the usual numbers are misleading, and what to look for in the data.

The numbers you think you're hitting

A rough survey of what senior developers guess before they start tracking, vs. what the data usually shows:

Three patterns jump out. Active coding is overestimated, roughly 2x. Slack and distraction are underestimated, also roughly 2x each. Meetings are underestimated because 30-minute meetings feel like 15 and 60-minute meetings feel like 30.

The reason the gap is so consistent is that memory of time use is compressed by engagement. Coding feels long because it's demanding; Slack feels short because it's light cognitive work. Your self-estimate is closer to "perceived effort" than to "wall clock," and the two are very different.

What to track, for a developer specifically

Generic categories don't help developers. You want the setup tuned to the shape of your work:

Productive (counts toward focus):

• Your editor (VS Code, Cursor, Xcode, JetBrains, Neovim)
• Your terminal
• Browser, conditionally on URL: GitHub, Linear/Jira, StackOverflow, documentation sites, localhost
• Figma, if you do any frontend UI work
• Slack, for code-relevant channels only (this one's contentious — default to distracting unless you're on oncall)

Neutral (excluded from productive + distraction counts):

• Finder, Spotlight, password managers
• System utilities
• Email (in moderation)
• Calendar app

Distracting:

• Slack, for general chat channels
• Browser, conditionally on URL: HN, Reddit, Twitter, YouTube (unless watching a technical talk), news sites
• Music apps if you consciously treat them as distraction (most developers don't — neutral is fine)

The conditionally on URL is the single most important item. Without per-site categorization, "browser" collapses into one bucket and the whole productive/distraction split becomes useless. Make sure the tracker you pick supports site-level tracking across every browser you use — not just Safari. See this post for the specifics.

The setup, in five minutes

Assuming you're using Focus Meter (or any tracker with equivalent features):

1. Install from the App Store.
2. On first launch, grant Accessibility + Automation permissions.
3. In Settings → Privacy → enable Browser URL Tracking and grant Automation for each browser.
4. Categorize your top 15 apps using the list above as a starting point.
5. Work normally for 2-3 days.

Don't look at the data during setup. It takes a couple of days for the categorization to settle, and the first-day numbers will be dominated by "Uncategorized" which is neither useful nor honest.

The first useful report: your week

After 5 working days, open Reports → Focus → This Week. The four numbers to pay attention to, in order:

1. Total productive time per day, trending. A reasonable senior-developer day is 3–4.5 hours of productive time. Under 2 is a red flag for the day (probably meeting-heavy). Over 5.5 is unusual and often means you have unusually flexible calendar control.

2. Longest uninterrupted productive session, per day. You want at least one 45-minute+ stretch per day. If your longest session is under 25 minutes all week, your day's structure is broken — likely notifications or calendar fragmentation.

3. Context switches per active hour. Under 15 is focused. 15–25 is normal. Over 30 and you are not doing deep work, no matter how the day felt. See this post for why this matters.

4. Distraction time, as a fraction of tracked time. 5-10% is pretty normal — nobody's perfect. Over 20% is a signal that the day has a structural problem, usually a poorly managed Slack or a browser distraction spiral.

The surprising finding most developers hit

Almost every developer who tracks for a full week finds that their biggest drag on productive time isn't the one they assumed. Most assume it's meetings. It's usually not.

The measurement tells you one of three things, and roughly speaking the distribution is:

• ~40% of developers: the drag is Slack. Long tail of small checks, fragmenting the day. Fix is ruthless batching.
• ~30%: the drag is browser distraction. HN, Reddit, or Twitter in the background, usually during context-switch moments. Fix is notification-free work sessions with the distraction sites blocked during them.
• ~20%: it genuinely is meetings, but usually because back-to-back scheduling leaves no usable blocks. Fix is calendar architecture (meeting-free days, time-blocking).
• ~10%: the day is actually focused and the feeling of "busy but not productive" comes from something else (impostor syndrome, unclear priorities, a project that requires research output that doesn't feel like output).

You need the data to know which category you're in. Without it you're guessing, and most developers guess wrong on the specifics even when they're right on the general shape.

What changes after you see the data

Two things, in most cases.

The story in your head updates. You stop telling yourself "I worked hard today and got little done." You start telling yourself "I had 2.1 hours of focused coding today, 1.8 hours of Slack-driven fragmentation, and 90 minutes of meetings." Even without any behavior change, the more honest story reduces a lot of the residual anxiety about how the day went.

Small, specific levers become visible. Instead of "I should focus more," you see that your worst days have 30+ switches per hour and Slack is the main driver. Now the intervention is specific: batch Slack to 10am, 1pm, 4pm for one week and measure the change. That's testable and usually works.