Time tracking for developers: keep your own record

Time tracking for developers usually means one of two products: a plugin that logs your activity, or an agent that screenshots your editor for an employer. This article is about neither. It is about keeping your own record of your own hours.

Most developers who want this are employees. You want an honest answer to why the “two-hour task” ate the week, something better than “various stuff” for the standup or the performance review, and proof of what the meeting load costs when you ask for fewer meetings.

If you freelance or take contract work, add invoicing to that list.

The good news is that developers are the easiest audience to write this for. Your day already produces timestamps, and you already know that raw activity data means nothing without intent.

What the record is for

A personal time record answers four questions that developer memory answers badly:

1. What did I actually do this week? A log beats a blank stare in the standup, and by review season it is the difference between “worked on the platform” and a list of shipped things with dates.
2. What does a task really cost? Estimates only improve when you can compare them with what happened.
3. Where did the week go? Feature work, debugging, review, meetings, and yak shaving all feel different in memory than they look in a log. “I spent eleven hours in meetings” is an argument; “the week felt busy” is not.
4. What do I invoice? If you bill clients directly, the record needs hours with notes a client will recognize.

None of these need a productivity score, and none of them are for your employer. They need a plain log you keep for yourself: what you worked on, for whom, and for how long.

The same manual time tracking method that works for consultants works here, with a few developer-specific twists below.

The minimum developer time entry

Keep each entry small enough that you will actually write it:

Field	Why keep it
Project or client	Which product, codebase, or client the work belongs to
Start and stop	Real boundaries, not a duration typed from memory
Note	The outcome, with a ticket or branch name when one exists
Billable status	Only if you invoice; employees can skip this column

The note carries the weight. “PROJ-142: fixed checkout race condition” still makes sense at review time or invoice time. “Coding” does not.

When the entry might reach a client or a manager, name the result in their words: what got fixed, shipped, or reviewed. The webpack fight stays in a private note.

Resist adding more structure. You do not need a task tree that mirrors the issue tracker.

Two kinds of labels cover most filtering you will ever do: one for where the work belongs (the project or client) and a tag or two for what kind of work it was (debugging, review, meetings). The second kind cuts across the first, so “how much of my week is review” gets answered across every project at once.

Both are optional; on a plain day, a note alone is enough.

Track sessions, not editor activity

The tools marketed at developers mostly watch the IDE: which files were open, which language, how many keystrokes. That data has two problems as a personal record.

First, an open editor is not work, and a closed one is not rest. Reading library docs, sketching a data model on paper, and staring at the ceiling until the bug’s cause clicks are all part of the task. An IDE tracker logs them as idle.

Second, activity has no intent attached. Thirty Stack Overflow tabs do not say which client the research was for, and a browser window cannot tell debugging from procrastination that looks like debugging.

You end up interpreting a noisy timeline after the fact, which is the same cleanup problem that makes automatic time tracking fail in general.

A session is the better unit. Start a timer when you sit down to a task, stop it when you switch to another task, a meeting, or another client, and let small interruptions roll into the block around them. The timer boundary is a decision you made, so the record needs no decoding later.

This is also the difference between your record and your employer’s monitoring, if you have any. Monitoring exists to answer someone else’s question about you. Your log answers your questions, stays under your control, and never has to flatter anyone.

Rebuild forgotten sessions from git

You will forget timers. Developers have an unfair advantage here: the work leaves timestamps everywhere.

git log --author=you --since=yesterday --format="%h %ad %s" --date=format:"%H:%M"

That one command gives you the skeleton of the day. Add pull request activity, CI runs, and calendar events, and most sessions can be rebuilt within a few minutes of the truth.

One trap: a commit timestamp marks the end of a stretch of work, not the start. If the log shows commits at 10:40 and 14:10, the afternoon session ended at 14:10 and started somewhere after lunch, not at 10:40.

Look at the gaps before commits, sanity-check against your calendar, and reconstruct the boundaries. That is still evidence, not guessing from the feel of the day.

Uncommitted work is the blind spot. Research, environment fights, and reading a codebase before touching it leave no git trail, and they are exactly the hours that vanish from memory first.

Which is the argument for the timer: git is a good backup, not a good primary record.

Tracked hours fix your estimates

Developers underestimate. This is so reliable it has folklore attached, but the folklore never comes with your own numbers.

Tracked time gives you those numbers. Write your estimate on the ticket, track the task, then compare. A few weeks of data usually shows two things:

• Your personal multiplier. If tasks run 1.6x your estimate on average, your next sprint estimate or quote gets multiplied by 1.6. No self-improvement required.
• Where the overrun lives. For most developers it is not the code. It is debugging, integration, environment setup, and the review round nobody scoped. Once the log shows that, you start estimating those parts explicitly instead of padding blindly.

This works for fixed-price work too. The hours never reach the invoice, but the total against the fee tells you what you earned per hour and what the next quote should be. Underpricing usually comes from untracked hours, not from a bad rate.

Billing when you write code for clients

Skip this section if you never invoice. Two developer-specific cases trip people up on invoices.

Debugging. Debugging the client’s system is normal billable work. Log it honestly and name the result: “Traced and fixed duplicate-webhook bug in payment flow” is a line a client pays without a fight.

Fixing a bug you shipped yourself is different: most freelancers write that time off. Track it anyway, under its own tag, so you can see what your rework costs. The billable vs non-billable split covers the general rules.

Rabbit holes. An hourly contract technically covers the four hours you spent on a dependency conflict. Whether you bill all four is a judgment call about the client relationship, but the decision should start from a real number. Round a recorded four hours down if you choose to; do not guess “maybe two” and lose the information.

Keep non-client work visible too. Proposals, invoicing, and learning a framework no client asked for come out of the same week you bill from. Hiding them makes your rate look healthier than it is.

Where TimeRetain fits

A developer’s time log is sensitive in a specific way: it holds the systems you touch, your late nights, your real meeting load, and, if you bill, client names and rates. That is not a record to hand to an employer or a vendor’s cloud.

TimeRetain keeps it on your device by default. Turn on Sync and an encrypted copy is stored on TimeRetain’s servers so the log follows you between machines. Leave it off and the hours never leave the laptop.

It is a manual timer with editable entries, which fits how this article says to track: start a session, label it, fix the record when real life got messy, and pull a CSV when you want to run your own numbers on estimate accuracy or draft an invoice.

The two label kinds above map directly. Timelines say where the work belongs: a timeline per project or client, nested when a project deserves its own total. Tags say what kind of work it was (debugging, review, meetings) across every timeline at once.

Both are optional. An entry can have neither, and a bare timer with a good note is already a working record; add timelines and tags when you want their totals.

Earnings are optional too: leave rates off entirely as an employee, or put them on the entries you bill. No agent watching the IDE, no activity score, no account required to start.

Start with one week

Do not build a system. For one week, track only real work sessions: project or client, start, stop, one-line note with the ticket. Rebuild anything you forgot from git at the end of the day, while the log still makes sense.

Then read it back. Check the meeting total against what the week felt like, and compare one or two tasks against what you estimated for them. If the record told you something your memory got wrong, and it almost always does, keep the timer running.