PUNCHCARD Get Punchcard $9

Time tracking for developers: how much of the day is actually in the editor

· 6 min read

Ask a developer how much of the day was spent in the editor and the answer is usually “most of it.” Measure it and the editor is often a third, with the terminal, the browser, and chat sharing the rest. The way to find out is to let the Mac record which app is in front and read the totals at the end of the day, without a timer and without giving anything Accessibility permission to read your window titles. Two weeks of receipts answers the question; this post is how to get them and what to do with the answer.

Why the editor fraction is worth knowing

The editor fraction is the closest thing a developer has to a single number for “time spent building.” It is not the same as productivity (an hour in the terminal debugging a deploy is real work), but it is the number that drops when meetings, reviews, and messages creep in, and the drop is invisible from the inside. A week where it falls from four hours to two feels like a normal week, because every interruption was individually reasonable.

Measuring it also exposes the workday’s actual shape. Developers tend to believe in the long focused afternoon. The receipt shows whether it exists. How to find your most productive hours is about using that to schedule the work that needs it.

The permissions problem, specifically for developers

Developers are more likely than most to read what a tracker wants before installing it, and to decline. Most automatic trackers ask for Accessibility permission so they can read window titles, which in a developer’s case means file paths, branch names, repository names, and the contents of every terminal tab title. Some ask for Screen Recording. Both are broad grants, and on a machine with access to production credentials, both are reasonable things to refuse.

An app-level tracker does not need either. macOS tells any app which application just became frontmost; that is public and needs no permission. Punchcard is built on that alone. It records app names only, never window titles, file names, URLs, keystrokes or screen contents, and appears in none of the Privacy & Security lists. It also contains no networking code at all, and the release build is set up to fail if a networking symbol appears, which is a stronger guarantee than a privacy policy. An app with no networking code covers how to verify that for yourself rather than take anyone’s word for it.

Setting up the measurement

  1. Write down your guess for the editor fraction and the terminal fraction. Be specific: “editor 60 percent, terminal 20 percent.”
  2. Open Punchcard. It appears in the menu bar; there is no setup wizard. Set a closing time.
  3. Work normally for two weeks. Do not tidy up your habits for the experiment.
  4. At closing time each day, a receipt prints: the day itemized by app with time per line, a day total, a stamp. If the Mac was asleep at the time, it prints late, headed SORRY WE MISSED YOU. Tear it off and keep it.
  5. On Sundays a week roll prints with the week’s totals, which is the number to compare against the guess.
  6. Compute: editor minutes divided by total minutes, per day and per week. Do the same for the terminal.

Reading a developer’s receipt

Patterns that appear consistently:

  • The editor and the terminal are separate lines. If you use an integrated terminal inside the editor, that time is counted as the editor. If you use a standalone terminal, it is its own line. Either is fine; know which you are measuring.
  • The browser is large and ambiguous. Documentation, the issue tracker, the pull request view, the CI dashboard, and the occasional detour all share one line. A browser total of three hours is worth splitting from memory: how much was reading docs, how much was reviewing.
  • Chat is the quiet one. The total is often under an hour. The number of switches into it is what costs, and the receipt does not count switches, only time. Read the real cost of switching apps all day with the receipt in hand.
  • Meeting days are obvious. A video call app at three hours with the editor at ninety minutes is a day that should be labeled as such, not felt as a failure.
  • Build and simulator tools show up. The iOS Simulator, a container tool, a database client: each gets a line. Decide which of these count as building for you.

What the receipt cannot tell a developer

  • Which repository or which ticket. App names only. There is no per-project tracking, and if you need that for billing it has to come from somewhere else.
  • Whether the editor time produced anything. Four hours in the editor could be a refactor or a rabbit hole.
  • Time in a remote session. If you work over SSH in a terminal, the terminal is the line, not whatever you were doing on the other end.
  • Idle time. There are no idle detection settings. Leave the editor open during lunch and lunch is in the editor. Lock the screen.
  • Anything across machines. No sync, no iPhone app. A second Mac keeps its own record; how to track time across two Macs covers combining them.

What to do with the editor fraction

Pick the one line that is eating the fraction and change one thing about it. Two common moves:

  1. If the browser is the problem, the culprit is usually the issue tracker and the PR view open in tabs all day. Move review to a fixed block and measure again.
  2. If chat is the problem by switches rather than by total, set it to deliver in batches or close it for the morning, and measure again.

Compare the week rolls before and after. A change that does not move the number was not a change. How to tell if a productivity change actually worked goes through the comparison properly, and the CSV export (one SQLite file at ~/Library/Application Support/Punchcard/punchcard.sqlite, exported from the app) is there if you would rather compute it in a script than read it off paper.

Tracking never expires and the first seven receipts are free. After that it is nine dollars once for two Macs.

Questions

Does it count the integrated terminal as the editor? Yes. It records the frontmost application, and an integrated terminal is a panel of the editor. A standalone terminal app is its own line.

I run code in a browser most of the day. Is it all just “browser”? Yes, and that is the honest limit of an app-level tracker. A dedicated desktop app for the tool, where one exists, gives it its own line. Otherwise the browser total is something you split from memory at the end of the day.

Can I get the raw data? Everything is in one SQLite file at ~/Library/Application Support/Punchcard/punchcard.sqlite, and the app exports CSV. Query it however you like. Burn the roll, in the app, deletes all of it.

Does it phone home? No. There is no networking code in the app. You can confirm that by watching for it in the Network tab of Activity Monitor, or by the methods in how to check what an app sends over the network.