WakaTime published its 2025 aggregate data earlier this year: across more than 500,000 developers who had the plugin installed and active, the average person logged 51 minutes of active coding per day. Not time with an editor open. Active coding time — keystrokes, file saves, actual work.
If your gut estimate was higher, you're not alone. WakaTime's numbers come from people who were actively trying to measure themselves, which means the actual average for developers who don't track at all is probably lower, not higher.
The point is not to be discouraging. The point is that if you're using a manual timer — start when you open your editor, stop when you close it — you are not measuring what WakaTime measured. You're measuring something different, and probably less accurate.
What a Manual Timer Actually Captures
Manual timers measure intent. You start one when you decide to work. You stop it when you decide you're done. Everything in between gets counted as work time, regardless of what actually happened.
In practice: you start the timer, open Slack to check something quickly, notice a thread, contribute to it for fifteen minutes, open the editor, get an email, answer it, come back to the code, realize you forgot what you were doing, spend ten minutes re-reading to rebuild context, write two lines, stop for lunch, forget to stop the timer. You end up with ninety minutes logged and maybe thirty minutes of actual coding.
No one is doing this maliciously. It is how interruptions work. The timer runs through them because stopping it would feel like accounting for every context switch, which is its own kind of overhead, and most people don't bother.
The second failure mode is selection bias. You remember to start the timer when you sit down for a focused session you're excited about. You don't start it for the twenty-minute debugging detour, the config file you needed to update before you could continue, the five minutes you spent reading a PR before your own code made sense again. Those sessions are work too. They don't get counted.
After a week, your manual tracking data looks like this: a series of logged sessions that feel accurate, because you do remember working during them, systematically missing the sessions that were brief, fragmented, or not "real coding" by some internal categorization you applied in real time. The total is plausible. The underlying picture is wrong.
What Automatic Tracking Captures Instead
Automatic time tracking at the OS level has no intent layer. It doesn't know whether you meant to work or not. It just records what applications have window focus, for how long, and in what sequence.
This changes what gets counted. The twenty-minute debugging session where you alt-tabbed between the terminal and a documentation page: counted. The config edit: counted. The PR review in the browser: counted. The Slack spiral: also counted, but as communication time rather than coding time, which is actually useful information.
Idle detection strips out the time you were technically "in" an app but had walked away — keyboard and mouse inactivity past a threshold. What remains is active time across all your applications, categorized by what kind of work each application represents.
The result is a different number from your manual timer, and it's a more honest one. Not necessarily higher — often lower, because the idle gaps get removed and the Slack time gets pulled out of "work time" and put in its own bucket. But it's accurate in a way that the intent-based timer isn't.
Why This Matters for Developers Specifically
Developers have more reason than most to care about accurate tracking, and less time to do it manually.
The measurement matters because developer output is genuinely hard to observe. You can count commits, but commits are a noisy proxy — a morning of deep design work that produces no commits looks identical to a morning of distraction from the outside. You can count tickets closed, but tickets vary in size by an order of magnitude. You can track hours, but only if the hours are real.
When you have accurate time data — not intent-based estimates but actual application-level logs — you can start asking questions that the estimates can't answer. How much of your editor time was interrupted by communication apps in the last month? Did your focused coding blocks get longer or shorter as a deadline approached? How does your Wednesday look compared to your Monday?
These questions sound like they'd require significant analysis. In practice, an automatic tracker produces them as a side effect of existing. The data is there. You just need something that collects it without relying on you to remember to press a button.
How xeve Implements This
The xeve macOS app is a Swift/SwiftUI menu bar process that runs at the OS layer, capturing window focus events from the system. The Windows app is a WinUI 3 system tray process doing the same thing. Neither is a browser extension or a web overlay. Both sit at the layer where the window focus events actually happen.
Sessions get categorized into nine fixed buckets: Development, Productivity, Communication, Browsing, Entertainment, Design, Writing, System, Uncategorized. Categorization is automatic based on app name and bundle ID. You can override individual apps in settings, but the defaults cover most developer environments without any configuration.
For coding specifically, the VS Code extension adds project-level resolution: not just "you were in VS Code for two hours" but "you were in the API project for an hour and forty minutes and the test suite for twenty." The extension sends heartbeats as you type, giving you a session-level breakdown that the OS-level tracker alone can't produce.
All of this syncs every 60 seconds. If the sync fails, sessions re-queue. Nothing drops.
What You Find When You Actually Look
The first thing most people notice is that their biggest time category is not what they expected. Some people discover their communication time is genuinely larger than their development time. Some find the opposite — they thought Slack was consuming their day, and the data shows their development blocks are longer than they felt.
The second thing is usually the pattern in the interruptions. Context switches have a specific shape in automatic tracking data: short sessions across multiple apps, clustered, followed by a gap (the re-orientation cost), then a longer session when focus was re-established. When you see this in your own data, it's recognizable immediately. You know exactly which days produced it and roughly what caused it.
WakaTime's 51-minute average is an aggregate number. Your number is specific to your work environment, your role, your current project's complexity, and how you actually structure your days. The aggregate gives you a calibration point. The only way to know your own number is to measure it automatically — intent-based timers will tell you what you wished you'd done, not what happened.
That gap is what automatic time tracking is for.