How to Track How Much Time You Spend Coding (2026 Guide)

What Counts as "Time Coding"

If you have ever sat down to answer "how much did I code this week" and drawn a blank, the honest reason is that the question is fuzzier than it sounds. Coding is not just fingers on keys. It is reading a stack trace, thinking through an approach before writing a line, prompting an agent and reviewing what it returns, and the ten minutes you spend rereading a diff before you trust it. Any method that only counts keystrokes is going to undercount you.

This matters more than it used to because so much output now comes from an AI agent rather than your typing. You can spend forty minutes steering Claude Code or Codex through a feature and produce a commit that took two minutes to type. A tool that measures keystrokes or diff size will call that a small task. A tool that measures your active session, including the terminal window where you were driving the agent, will call it what it was. This is why the definition you start with decides whether the final number is honest or just quiet about what it left out.

How to track your coding time, step by step

Here is the practical path, in the order it works, starting from "what am I even doing this for" and ending at a number you would show someone else.

1. Decide why you are tracking before you pick a tool. Billing a client, sanity-checking an estimate, understanding your own patterns, and proving what you shipped are four different jobs, and they tolerate different amounts of error. If you are billing or proving, you need a defensible record. If you just want a rough sense of your week, a lighter method is fine. Naming the reason up front saves you from over-building or under-building the setup.
2. Rule out the manual timer as your only method. A start/stop timer is fine as a spot check, but as a sole source of truth it depends on you remembering to click it during the exact moments you are least likely to remember: mid-debug, mid-flow, mid-panic before a demo. In practice, reconstructed timesheets almost always round up, because nobody reconstructs a missed hour and rounds it down. This is why a timer works fine as a supplement and fails as a foundation. If you want the full case, manual timesheets lie walks through why.
3. Add a passive layer that does not need you to remember anything. This is either an editor plugin like WakaTime, which records active time and per-language stats inside one editor, or telemetry from a broader tracker that also covers terminal and CLI work. If most of your day lives in one IDE, a plugin is a reasonable start. If you also spend real time in the terminal driving an agent, a plugin alone will miss it, and you will want an editor-agnostic tracker instead. See best time tracking tools for developers for how the two compare, and DevClocked vs WakaTime if you are specifically weighing the plugin option.
4. Use your git history as a free baseline, not as the final answer. You can reconstruct a rough session length from commit timestamps with nothing installed, grouping commits that sit close together and treating long gaps as breaks. This is a genuinely useful cross-check. It is not an accurate clock, because commit size stopped mapping to effort once AI started writing large diffs in seconds. Tracking coding time from git covers how to build this baseline properly and where it breaks.
5. If you drive AI agents from the terminal, make sure your method sees that. A huge and growing share of real coding time now happens outside the editor window entirely, in a terminal running Claude Code, Cursor, or Codex. You will often see this show up as a suspiciously light week in the tool's dashboard even though you know it was a heavy one, and that gap is usually the terminal time going uncounted. Coding time tracker without an IDE plugin covers the editor-agnostic option built for exactly this.
6. Review weekly instead of daily. A single day of coding stats is mostly noise, a bad meeting day or a long debugging session will skew it. A week shows when your best hours land, how much time slides into meetings and reviews versus writing, and whether your estimate-to-actual ratio is improving. The pattern over time separates a useful log from a vanity chart, not any single day's number. Coding stats covers what is worth looking at once you have a few weeks of data.
7. Keep the record if you ever need to show it, not just glance at it. A number only you can see is a private habit. A number backed by an audited trail of real activity is something you can hand to a client, an employer, or your own future self without asking them to take your word for it.

Common mistakes

A few habits quietly wreck the accuracy of self-tracking, and they are worth naming because they are easy to fall into without noticing. The first is trusting a manual timer as the whole system, then rounding every gap up "to be safe," which compounds into a number nobody should trust, including you. The second is assuming an editor plugin captures your full day when it only sees one editor, missing the terminal and any agent session you ran from the command line. The third is treating your git graph as an accurate clock, when it is really a benchmark that AI has made less reliable, not more. Almost always, the fix is the same. Measure activity as it happens instead of reconstructing it later from memory or from a diff.

Where DevClocked fits

Full disclosure: I build DevClocked, so take the placement with that in mind. If your goal is a quick personal sense of your week and you are disciplined about a timer, a plain timer plus a spreadsheet is genuinely enough, no tool required. DevClocked earns its place when you want more than a private guess. It leads with leverage and output, measuring what you and your AI agents shipped, using a git baseline (no per-editor plugin needed) plus telemetry from a lightweight extension and an editor-agnostic CLI that covers terminal and agentic sessions, learned together into a calibrated number. That is the version of "how much time did I spend coding" that holds up when you need to show it, not just remember it.

Related Guides

• Developer time tracking: the complete guide: the four methods compared side by side.
• Track coding time from git: building the git-based baseline and its limits.
• Coding stats: what to look at once you have data.
• Coding time tracker without an IDE plugin: the editor-agnostic option for terminal and agent work.
• Best time tracking tools for developers: the full ranked comparison.