Time tracking for developers: keep your own record

Time tracking for developers is a personal record of your own hours. It is not a plugin that logs your activity. It is not an agent that screenshots your editor for an employer.

You want a real answer to why the “two-hour task” ate the week. You want something better than “various stuff” for standup or review. You want proof of what meetings cost when you ask for fewer of them.

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

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. By review season it is a list of shipped things with dates, not “worked on the platform.”
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. Calendar duration misses prep and overrun. The timer includes them.
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.

Put the project or client on a timeline. Tag the kind of work: debugging, review, meetings. Then “how much of my week is review” works across every project.

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

A day that still makes sense next month

Date	Start	End	Project	Note	Kind	Total
Aug 12	09:10	10:40	Checkout	PROJ-142: fixed checkout race condition	Debugging	1h 30m
Aug 12	10:40	11:20	Checkout	Reviewed PR #418 on payment retries	Review	40m
Aug 12	11:30	12:20	Platform	Sprint planning	Meetings	50m
Aug 12	13:15	14:10	Checkout	Read payment-flow docs (rebuilt from git)	Research	55m

The last row has no file change until 14:10. Those hours are a reconstruction from the later commit, calendar, and notes. A commit may mark when a snapshot was created, not when the work ended.

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 activity log after the fact. That is the same cleanup problem that makes automatic time tracking fail.

A background activity log can sit as a safety net you classify later. The record you keep is still the session you started on purpose.

A session is the better unit. Start a timer when you sit down to a task. Stop it when you switch tasks, meetings, or clients, and let small interruptions roll into the block. 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="YOUR_GIT_AUTHOR" --since=yesterday --format="%h %ad %s" --date=format:"%H:%M"

Replace YOUR_GIT_AUTHOR with the name or email in your Git author settings.

That one command gives you the skeleton of the day. Add pull request activity, CI runs, and calendar events. You can often reconstruct a session’s rough boundaries.

Treat those hours as a floor, not the truth. Meetings, review, and uncommitted research leave no commit trail. A squash, rebase, or large AI diff can also fool the interval math.

If you invoice rebuilt hours, mark the row as reconstructed. Do not bill it as measured clock time.

One trap: a commit can mark the end of a stretch of work only when you committed at the end of that stretch. The command above prints the author date (%ad), which may differ from the committer date (%cd). If the log shows commits at 10:40 and 14:10, use the gaps, calendar, and notes to estimate when the afternoon session ran.

Look at the gaps before commits, check them against your calendar, and rebuild the boundaries. That is better than guessing from the feel of the day. It is still an estimate.

Uncommitted work is the blind spot. Research, environment fights, and reading a codebase leave no git trail. Those are 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. The total against the fee tells you what you earned per hour, and what the next quote should be. Underpricing often 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 when the hourly contract covers the work and it is in scope. Log it and name the result: “Traced and fixed duplicate-webhook bug in payment flow” is a line a client can understand.

On hourly work, testing and debugging stay on the invoice. Write off a careless mistake after you already called the work done, or time spent learning a skill you claimed to have.

Track that rework under its own tag so you can see what it 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. Start from the real number.

If you bill less, put the smaller figure on the invoice and leave the four hours in the log. 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 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 is a manual timer that keeps the log on your device. Start a session, put it on a project or client timeline, tag the kind of work, and write the outcome in the note. No account, and nothing watches your IDE.

If you invoice, put a rate on that client. Export a CSV into the sheet or invoice you already use. Sync is optional. Leave it off and the hours stay on the machine.

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. 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.