Time Management
Why Unbillable CI and Code Review Should Be Their Own Task
Unbillable time tracking for developers usually fails in one quiet place: CI, code review, and Slack get dumped onto Implementation. The ticket looks busy. The estimate looks cursed. The invoice either hides the glue work or bills a client for waiting on a pipeline you would have run anyway.
Split the leaf work. Keep Implementation for building. Give Code review / QA its own task. Give CI / release a task if you babysit pipelines. Give Support or Internal/admin a home for Slack that was never the build. You cannot steer a week you cannot name.
This is not a lecture about charging for every green check. Some review is billable. Some CI is overhead. The point of a separate task is honesty: you can decide the commercial rule after you can see the hours. Mixing them into one blob makes both decisions fake.
What gets lost when everything is “Implementation”
A freelance full-stack engineer’s Tuesday is rarely eight hours of feature code. It is a review on a PR you did not write, a flaky job you did not plan, a Slack thread that turns into a scope question, then ninety minutes of actual Implementation. If the only task on the project is “Build the dashboard,” every one of those minutes inflates the same bar.
That wrecks three conversations you will have later:
- Estimates vs actuals. You quoted Implementation. The overrun was review and CI. You “missed” a number that was never the work you estimated. Meetings on the same leaf have the same problem — we already wrote why meetings should not live on Implementation. CI and review deserve the same split.
- Invoices. Clients understand “code review, 1.4 hours” and “pipeline recovery, 0.6.” They do not understand why “Homepage” took 11 hours when the diff was small. Line items need names humans can defend.
- Your real hourly rate. Glue work is still time. If it is unbillable, it still lowers the rate you actually earned. Hiding it inside a billed task makes you feel profitable until the year-end math.
GitHub will not save you. Commit history is not a timesheet, and a PR title is not an invoice line. If you need that argument in full, it is here: why your GitHub history isn’t a timesheet. The fix is a task named for the activity, not a ritual of mining the repo on Friday.
A taxonomy small enough to reuse
You do not need a new ontology per client. You need a short list you will actually start a timer on. This is enough for most software consultants:
- Discovery — unpaid or billed research before you promised a build.
- Architecture — design docs, spikes, “which queue.”
- Implementation — writing the thing you quoted.
- Code review / QA — reading someone else’s diff, writing review, verifying a fix.
- Meetings — standups, pairing that was not implementation, client calls.
- Support — production questions, “is this down,” Slack that is the product.
- Internal / admin / sales — proposals, your own CI on a template repo, bookkeeping.
Add a CI / release task on projects where you regularly watch pipelines, cut tags, or babysit flaky jobs. If that is rare, park a one-off under Support or Internal — but do not let it hide inside Implementation “because the deploy is part of the feature.” Deploys that take forty minutes are a different job than the feature.
Billable is a flag, not a task name. Code review for a client’s team can be billed. Reviewing an open-source dependency for yourself is not. Same activity, different commercial home. Track the activity first. Mark billable vs non-billable second. If you need the broader rule set, start with billable vs non-billable time.
Slack looks are not “a few seconds”
Context switching is the tax nobody invoices and everybody pays. A “quick look” at CI, then Slack, then the PR, is often twelve minutes before you are back in the editor. Those minutes are real. They are also how 0.1-hour rounding (6 minutes, if you use it) stops feeling like padding and starts feeling like the smallest honest unit.
You do not need a task per Slack channel. You need a default: if the message is about this client’s running project, it is Support or Meetings. If it is your community, your accountant, or another lead, it is Internal / admin / sales. The failure mode is leaving the Implementation timer running while you argue about a weekend deploy that is not the feature.
Admin and in-between work already has a home on this blog — how it quietly eats the best hours. CI and review are the developer-shaped version of the same leak. Name them or they become “Implementation went long again.”
What to do with the hours once they exist
A named task is only useful if you look at it. Once a week, run a report for the client or project and pivot by task. If Code review / QA is 30% of the week and you quoted a pure build, that is a scope conversation or a rate conversation — not a personal failing. If CI / release is huge and unbillable, it belongs in your real hourly rate, not in shame.
Fixed-price work is where this split saves you from lying to yourself. Implementation can still be inside the cap. Review rounds you did not price can show up as the overrun. That is how you decide whether the next project needs a review allowance, a support retainer, or a polite no. Reports that actually get used are listed in seven reports worth running and the reports guide.
A Friday check that takes ten minutes
Open History for the week. If you see a four-hour Implementation block that included a review session and a red pipeline, split it — even after the fact — so next week’s estimate is not built on a fiction. Then generate one report: this client, this week, pivot by task. If you cannot explain each row in one sentence, the task names are still too cute.
Where MinuteShark fits (after the habit)
You can do this split in any tracker that lets time live on a task. MinuteShark is built for that hierarchy: Workspace → Client → Project → Task → optional Subtask, and the clock belongs on the task. Start the review task from dashboard search when you open the PR. Lock or close Implementation if you do not want more time on it. Subtasks on Standard are useful when one review pass should stay a leaf under a feature without merging the hours.
If you forgot to switch, do not reconstruct from git blame. In MinuteShark AI, say something like “I forgot to log 30 minutes on yesterday’s standup task” — or name the review task — then edit the confirmation card before Confirm. Nothing is written until you confirm. Many actions can be reverted from chat. The assistant will not silently reclassify your week.
Rounding, if you use it, stays a setting: off by default, rounds up, original duration kept, BILLABLE shown when it is on. Review that lands at 10 minutes becomes 12 at 6-minute rounding. That is a conversation you can have because the task said “Code review,” not because a repo graph implied it. More on the mechanic: time rounding.
MinuteShark is not a GitHub integration catalog and does not pretend commit activity is billing. It is a daily time OS for consultants: the right leaf, an honest report, an invoice from that report and a cost profile when you are ready. Split CI and review first. The tool is there to keep the names from collapsing again.