Focus Tracking for Software Developers: What To Measure and Why
Developers are hard to measure because the visible work and the valuable work are not always the same thing.
Eight hours in an editor can be shallow. Two hours fixing a production bug can be the most valuable work of the week. A day with no commits can still be full of code review, design review, debugging, or architecture. That is why developer focus tracking should never pretend to be a performance score.
It should answer a narrower question: what shape did your attention take?
Start with the coding surface
For most Mac developers, the core productive tools are predictable:
- VS Code, Xcode, or another editor
- Terminal, iTerm2, or Warp
- GitHub
- Documentation
- Linear, Jira, or another issue tracker
Focus Meter tracks editors and terminals at the app level. It tracks supported browser URLs at the domain level. That means VS Code, Terminal, GitHub, and documentation can show up as separate signals instead of collapsing into one vague "Computer: 8 hours" story.
The VS Code tracking guide is the best place to start if you want a concrete example.
Measure ratios, not absolutes
Raw editor time is useful, but it is not the whole truth.
The better review is a ratio:
| Signal | What it usually means |
|---|---|
| Editor + terminal | Implementation, debugging, build/test loops |
| GitHub + Linear | Review, planning, collaboration |
| Slack + meetings | Coordination and interruption |
| Distracting browser time | Avoidance, breaks, blocked-task drift |
A healthy week can have low editor time if you were reviewing a large release. A bad week can have high editor time if you spent it thrashing between files without finishing anything. The ratio gives context.
The developer profession guide shows a representative weekly split.
Slack is the fragmentation metric
Developers often underestimate communication because individual checks are tiny.
You do not remember a 38-second Slack check. You remember the feature you were building. But the code remembers. Your brain has to reload the task, the file, the stack trace, the failing test, and the next step.
That is why Slack time is less important than Slack switching. If your editor blocks are constantly broken by Slack, your day may feel exhausting even when total communication time looks reasonable.
Read the Slack tracking guide if this pattern sounds familiar.
Browser time needs domains
For developers, browser time can be extremely productive:
- GitHub PR review
- API documentation
- Stack Overflow
- Internal dashboards
- Cloud consoles
- Search while debugging
It can also be pure drift:
- Reddit between builds
- YouTube after a hard bug
- X while waiting for CI
- News tabs during a compile
The app name cannot tell those apart. You need domain-level tracking. The browser tracking guide explains how to set that up.
Do not turn this into surveillance
Developer focus data is useful because it is personal. It gets worse when it becomes managerial.
Focus Meter has no team dashboard, no admin portal, and no cloud account. That is intentional. If developers feel watched, they optimize the metric. If the data stays private, they can use it honestly.
The right question is not "did I work enough?" It is:
- What interrupted me?
- When did I get real coding blocks?
- Which apps made the day feel fragmented?
- Which domains were research and which were avoidance?
- Did my week match the kind of work I thought I was doing?
A weekly developer review
Every Friday, look at five things:
- Longest editor block.
- Total editor plus terminal time.
- GitHub and documentation time.
- Slack and meeting time.
- Distracting browser time.
Then write one sentence: "This week was mostly ____."
Mostly building. Mostly reviewing. Mostly talking. Mostly recovering from interruptions. Mostly blocked.
That sentence is more useful than a perfect dashboard because it forces the data into a decision. If the week was mostly talking and you needed to ship, protect two mornings next week. If the week was mostly coding but nothing shipped, look for thrash. If the week was mostly distractions, fix the environment before blaming motivation.
What Focus Meter can and cannot know
Focus Meter can know that VS Code was active. It cannot know whether the code was good.
It can know that GitHub was active. It cannot know whether the PR review caught a critical bug.
It can know that Slack fragmented your afternoon. It cannot know whether that incident was worth it.
That limitation is good. The tool should give you the outline. You supply the judgment.
For developers, that outline is already valuable: editor, terminal, GitHub, docs, Slack, meetings, and distraction, all local to your Mac.