Most developers work on multiple projects in any given week. A feature for the main product, a bug fix in a library, a side project, some infrastructure work. At the end of the week, the question is always the same: where did the time actually go?
Manual time tracking is the obvious answer, and it is also the one that consistently fails. Starting and stopping timers breaks flow. Forgetting to switch timers means inaccurate data. And nobody wants to reconstruct their workday from memory at 5 PM on Friday.
The better approach is automatic tracking that captures coding time without any manual input.
The Manual Timer Problem
Tools like Toggl and Harvest are excellent for client billing. You start a timer, label it "Project Alpha," work for a while, then stop it. The data is clean and ready for invoicing.
But for understanding your own coding patterns, manual timers have fundamental problems:
- You forget to start them. You sit down, open VS Code, and immediately start working. Twenty minutes later you remember the timer.
- You forget to switch them. You jump from Project A to Project B to fix a quick bug. The timer is still running on Project A.
- You forget to stop them. Lunch break, a meeting, a phone call — the timer keeps running on a project you left 45 minutes ago.
- They interrupt flow. The act of managing the timer is itself a context switch. You are optimizing for data accuracy at the cost of the thing you are trying to measure.
The result is that manual time tracking data is consistently wrong, and developers who try it usually abandon it within two weeks.
Editor Plugins: Better but Incomplete
WakaTime pioneered the editor plugin approach. Install a plugin in VS Code, JetBrains, or Vim, and it automatically logs your coding time by detecting keystrokes and file saves. No timers to manage. The data includes project, language, file, and branch breakdowns.
This is a significant improvement over manual tracking, and if your only goal is to measure time inside your editor, WakaTime does it well.
The gap is everything outside the editor:
- Debugging in the browser — WakaTime does not see Chrome DevTools sessions
- Reading documentation — time spent in MDN, Stack Overflow, or API docs is invisible
- Terminal work — build scripts, deployments, SSH sessions, database queries
- AI-assisted coding — Claude Code and Cursor sessions happen outside traditional editors
- Design tools — reviewing Figma, testing in simulators, writing in Notion
- Code review — reading PRs in the browser is not captured by editor plugins
For a developer who spends 40% of their time in VS Code and 60% everywhere else, WakaTime captures less than half the picture.
System-Level Tracking: The Full Picture
A system-level tracker like xeve runs at the OS level and sees every application you use. VS Code, Chrome, Terminal, Figma, Slack, Xcode — everything is tracked automatically and categorized.
Combined with editor-level plugins, you get two layers of data:
Layer 1 — System tracking (what app is active):
- 3 hours in VS Code (Development)
- 1.5 hours in Chrome (mixed: Development + Browsing)
- 45 minutes in Terminal
- 30 minutes in Slack (Communication)
- 30 minutes in Figma (Design)
Layer 2 — Editor tracking (which project, which language):
- 1.5 hours on api-service (TypeScript)
- 1 hour on mobile-app (Swift)
- 30 minutes on docs-site (MDX)
Together, they answer the complete question: not just "how much did I code" but "how did I spend my entire workday, and within my coding time, which projects got the most attention."
Setting Up Automatic Multi-Project Tracking
Here is how to set up complete automatic tracking in under 5 minutes:
1. Install the system tracker. Download xeve for Mac or Windows. It runs silently in your menu bar or system tray. Every app switch is logged automatically with no configuration needed.
2. Add the VS Code extension. xeve's coding analytics extension detects your active project, language, and file automatically. It sends heartbeats to your dashboard so you get per-project breakdowns alongside your system-level data.
3. Track Claude Code sessions. If you use Claude Code, the heartbeat hook integrates automatically. Every AI-assisted coding session shows up in your dashboard with project and duration data.
4. Connect GitHub. Link your GitHub account to see commits, pull requests, and reviews alongside your time data. This creates the input-output view: hours spent coding versus code actually shipped.
5. Open your dashboard. Everything flows to xeve.io/dashboard. The coding page shows per-project time, language breakdown, daily trends, and weekly comparisons. The overview page shows how coding time fits into your broader workday.
What Good Multi-Project Data Looks Like
After a week of tracking, you will have data like this:
- api-service: 12h 30m (TypeScript 85%, SQL 15%)
- mobile-app: 6h 15m (Swift 100%)
- devops-scripts: 2h 45m (Python 60%, YAML 40%)
- docs: 1h 30m (Markdown 100%)
This is immediately actionable. If you expected to spend 50% of your week on the mobile app but the data shows 28%, something is pulling you away. Maybe it is meetings. Maybe it is unplanned API work. Either way, you can see it and adjust.
Over months, the data reveals longer-term patterns. Which projects consistently take more time than estimated? Which languages slow you down? Do you code more in the morning or afternoon? Does your output change on days with more meetings?
Beyond Time: Correlating Productivity Signals
The real power of automatic tracking is correlation. When you track coding time alongside other signals — GitHub activity, meeting load, app switches, even sleep and exercise data — patterns emerge that no single metric can reveal.
For example: developers who had fewer than 3 context switches per hour committed 40% more code on average. Developers who coded within 30 minutes of waking up had higher output than those who started with email. Days with more than 3 hours of meetings consistently showed lower commit counts.
These are not universal rules. They are personal patterns that only become visible with enough data over enough time. And the only way to get that data is to track automatically, across every project and every tool, without asking developers to do anything manually.
The best time tracker is the one you never think about. Install it, forget it, and let the data accumulate. The insights will follow.