Developers have the most rational objection to time tracking of any profession: tracking is context-switching, and context-switching is the enemy of the work.
The objection is correct. Most time trackers are built on the assumption that the user is happy to alt-tab to a web dashboard, type a description, click a button, alt-tab back, and lose three minutes of mental cache reloading the function they were inside. Over a week, that's an hour. Over a month, it's a day. Over a year, it's two work-weeks of lost flow — for a record that the developer's contract probably accepted on trust anyway.
This post is for the developers who do need to track — freelancers, contractors, agency-side engineers, anyone billing hourly or being measured on time. It's about doing the tracking with as little friction as the work permits, and getting honest data out the other side without rebuilding your workflow around it.
The developer-specific problem
A typical engineering session is not "code for 4 hours, ship, done." It's:
- 12 minutes orienting in an unfamiliar file,
- 40 minutes writing,
- 20 minutes reading a related PR,
- 8 minutes in Slack about an unrelated thing,
- 90 minutes head-down on the actual change,
- 25 minutes fighting CI,
- 15 minutes on a code review for a colleague,
- 6 minutes context-switching back into your own task.
Some of that is billable. Some is collateral. Some belongs to a different project. The clean "start timer, do work, stop timer" loop is a fiction. Real engineering days are interleaved.
A good developer tracking workflow accepts this. It doesn't try to capture every micro-switch — it captures the blocks honestly and lets you split or relabel afterward when needed.
What developers should track
Track at the granularity of the billing unit, not the task unit. If you bill in 30-minute increments, tracking to the minute is wasted precision. If you bill by ticket, tracking to the ticket is enough.
The categories that matter:
- Direct ticketed work — the issue or PR you're moving forward. Easy to label, easy to bill.
- Code review for the team — billable on most contracts, lost on most timesheets.
- Pairing and unblocks — short bursts of helping a teammate. Usually billable; almost always undercounted.
- Infrastructure / DevX / CI — work that doesn't ship to users but does ship to the team. Often goes against a "platform" or "infra" project; sometimes against the project that triggered it.
- Meetings — standup, planning, retros, ad-hoc syncs. Track them; you don't have to enjoy them.
- Deep solo time on a hard problem — the most valuable work you do; also the most underbilled because there's no ticket to attach it to. Track it against the parent project.
The single most useful classification is billable vs internal. Everything else is reporting nicety. If you can answer "how many billable hours did I do this week?" honestly, you have the foundation.
Start the timer from the issue, not the tracker
The killer workflow for developers is starting a timer from where your work already lives.
If you live in Linear, you should be able to pick a Linear issue inside your time tracker — by identifier, by recent activity, by current sprint — and start a timer against it. No tab switch, no copy-paste of an issue title, no manually rebuilding the link between the tracked hour and the work.
Same for Asana. Ayron's Linear and Asana integrations are built around this primitive: connect once, link the relevant Ayron projects to their Linear/Asana counterparts, and your assigned issues become a one-click timer surface in the macOS app.
The deeper pieces are covered in the integration posts:
- Time tracking for Linear, without context-switching out of an issue
- Time tracking for Asana, without leaving Asana's hierarchy
The result is that the tracked hour and the issue carry the same identity end-to-end. When you invoice, the line items already make sense to the client because the names match what they see in their own tool.
A workflow that survives a real engineering day
The goal is a tracking discipline you'll still be doing in week six, not week one.
Start-of-day: pick the issue, not the day
When you sit down, the first action is starting the timer against the issue you're about to work on. Not opening Slack. Not catching up on email. Start the timer first, then context-load.
Why: the moment you decide what you're working on is the only moment you have full clarity about it. Five minutes later you're in the file and the decision is lost.
In Ayron, ⌘K → type the issue identifier → return. The timer is running. You're back in your editor.
Mid-day: switch deliberately
When you switch contexts — to a code review, a pairing session, a meeting — switch the timer with it. Not because the bookkeeping demands it, but because the switch is the moment your brain already context-switched. Tracking it costs no additional cognitive load because the cost has already been paid.
The hard part is the in-between. The 8-minute Slack tangent. The 4-minute CI check. Most developers don't switch the timer for those and that's fine — the cost of granularity isn't worth it. If a "tangent" lasts more than ~15 minutes, it deserves its own timer. Below that, it gets folded into the surrounding block, and that's honest enough.
End-of-day: stop, write one line, close the laptop
The single most underrated practice in developer time tracking: write one sentence in the note field before you stop the timer. Not a paragraph. One sentence: "Implemented retry logic for the webhook dispatcher; needs unit tests Monday."
Why: that one line is what saves you on Friday afternoon when you can't remember what Wednesday morning was about. It's also what makes the AI weekly report useful instead of generic, because it has actual context to summarize.
Friday: invoice and stop carrying the week in your head
End-of-week reconciliation is short if mid-week was honest:
- Look at the weekly view per client.
- Anything mistagged or split across the wrong project: fix it now, while you remember.
- Generate the invoice. Send it. Stop carrying the week in your head over the weekend.
If you're on a salaried contract, replace "invoice" with whatever timesheet your engagement requires. Either way, the work happens on Friday afternoon, not next Tuesday.
Tools that respect a developer's setup
A developer Mac is a precision instrument: a terminal, an editor, a browser with twelve docs tabs, maybe Docker, maybe a VM, maybe a simulator. A time tracker that demands a thirteenth tab is a tax on the work.
What "Mac-first" should mean for a developer:
- Menu bar timer — current task, elapsed, one click to switch. Always visible without alt-tab.
- Global keyboard shortcut — ⌘K palette, type, return. Faster than opening the app.
- Issue tracker integration — Linear and Asana issues bookable as timers directly. No copy-paste.
- Local-first data — your tracked hours work offline, sync when connected. The CLI engineer in you will appreciate this.
- Plain export — JSON, CSV, or via webhook to your own dashboard. Your data is yours.
A non-trivial number of developers eventually pipe their time_entry.stopped events into a personal Notion or a private Postgres for their own analytics. Ayron supports this through its Zapier and webhook playbook. The tracker should be the source of truth; what you do with the data after is up to you.
What about automatic tracking?
A reasonable question — why not just auto-track everything based on which app is foreground, which repo is checked out, which Linear issue is in the URL bar?
There's a real case for automatic tracking, and Ayron supports it (with privacy-aware local categorization). But for billing specifically, automatic tracking has a structural problem: it captures what you did, not which client to bill it to. Reading code-review.com doesn't tell anyone whether the review was on Client A's PR or Client B's. The mapping back to billability still requires a moment of judgment.
The right pattern, in our experience: automatic tracking for personal awareness (where did your week go? how much deep work did you get?) and explicit timers for billable work (which client did this hour belong to?). Ayron lets you run both at the same time without one corrupting the other.
When tracking is the wrong answer
Honest note. Tracking is the right answer when:
- You bill hourly or are on a contract that measures hours.
- You want to know your effective rate vs your headline rate.
- You want estimate-vs-actual visibility on the projects you take.
Tracking is the wrong answer when:
- You're a salaried full-time employee and your contract doesn't ask for it.
- You bill flat-rate per project with no overrun risk and stable scope.
- You're so early in a project that tracking would force a structure that doesn't exist yet.
The trap is the salaried developer who tracks anyway "for productivity" and ends up self-surveilling for no business reason. The hours aren't worth more visible than less; do the work.
A simple next step
Pick one client engagement. Track every hour spent on it for one week. Don't change your behavior; just capture it.
On Sunday night, read the weekly AI report. It will tell you whether the engagement is profitable at the rate you quoted, whether the scope is matching the work, and whether the time is going into the parts of the engagement you assumed it was.
If even one of those answers surprises you, you've found the thing tracking is actually for.
Ayron is a Mac-first time tracker, invoicing tool, and AI weekly report in one app, built for freelance and contract developers. Linear and Asana integrations included. Free to try; Pro is $12/mo annual ($15/mo monthly). Get started.