PUNCHCARD Download Get Punchcard $9

How much of your week goes to code review, measured on a Mac

· 7 min read

There is no general figure worth trusting for your team, but you can measure your own week without much effort. Switch on website itemizing so your code host prints as its own line, read a week of daily receipts, and cross-check a few days against the times you submitted reviews. You end up with your review time as a range you can defend, without timers or editor plugins.

Why review time is hard to feel

Review arrives in fragments. A notification pulls you into a two-file change for ten minutes. A long thread eats half an hour before lunch. A re-review after fixes takes five minutes, then another five. Each piece feels short, and none of them feels like the main work of the day, so they vanish from memory by evening.

Review also fills gaps: the stretch before standup, the wait for a build, the last half hour when you do not want to start something new. Gap work is the easiest kind to undercount. The only way to know the weekly total is to add it up, and nobody adds up fragments by hand.

Getting your code host onto its own line

Punchcard is a Mac menu bar app that notices which app is in front during your day and prints a receipt at the closing time you set: your top five lines with time on each, the rest as MISC, and a day total. Out of the box it records app names only, so all your browser time is one line, and review in a browser disappears into it.

The fix is itemized browsing, added in version 1.3.0 and off by default:

  1. Open Punchcard’s Settings and switch on “Itemize websites”.
  2. The next time a supported browser is in front, macOS asks once for that browser, for example “Punchcard wants access to control Google Chrome”. Allow it.
  3. Settings shows each browser’s state: Itemizing, Blocked (with a Fix in Settings button), Waiting for your OK, or Checks in when you open it.

From then on, time in Chrome, Brave, Edge and Vivaldi (including their Beta, Dev, Canary and Nightly builds) prints as the sites you used. GitHub gets its own line, competing with your editor and chat for the top five. A self-hosted code host prints under its bare site name with a globe. Safari, Firefox and Arc are not itemized, so if you review in one of those, their time stays a single line. Tracking website time in Brave, Edge or Vivaldi on a Mac covers setup per browser.

What the code host line really contains

Before reading the number as “review time”, be honest about what is inside it.

It overcounts. The code host line is everything you did on that site: reviewing, but also reading issues, checking CI results, writing descriptions for your own pull requests, and browsing other repositories. Punchcard keeps the site name only, never the path or page title, so it cannot separate these.

It also undercounts. If you check out a branch and review it in your editor, that time is on the editor’s line, not the code host’s. The same goes for review discussions in chat or on a call.

So the code host line is not your review time. It is the part of review that happens in the browser plus some other browser work. For most people that is still the bulk of it, and a range is more useful than a guess.

Narrowing the range with the CSV

A few days of cross-checking tightens the number considerably.

  1. Export the CSV from Punchcard. It has one row per session with the start time, end time, app, seconds, and the site when itemized browsing is on.
  2. Open a pull request you reviewed and look at its timeline, which shows when you submitted each review.
  3. Find the code host sessions in the CSV that end near those times. Those sessions are review.
  4. Sessions on the code host with no review nearby are probably issues, CI or your own pull requests.

Do this for three days and you will know roughly what share of the code host line is review for you. Apply that share to the rest of the week. If you review in the editor too, keep a tally for the same three days of when you did, and add the editor sessions from the CSV that match.

Export your time data to CSV and keep it forever walks through opening the file in a spreadsheet.

Reading a week of receipts

Once the code host has its own line, a week of receipts tells a clear story. An example, with invented round figures: an editor at 3h 40m, GitHub at 1h 50m, chat at 1h 10m, a terminal at 40m, Mail at 25m, and MISC at 30m. That is a day where review in the browser took about a quarter of the Mac time.

Things worth watching across the week:

  • The ratio of code host to editor. If review regularly rivals your own coding time, that is worth knowing whether or not it is a problem.
  • Review in the first hour. Many developers start the day by clearing reviews, and it can quietly push the first real coding session later. How long it takes you to actually start work in the morning looks at that pattern.
  • Review after your closing time. If the code host shows up on late sessions, reviews are spilling into evenings.
  • The Sunday week roll. Punchcard prints one each Sunday, which is the easiest place to compare weeks.

What to change once you know

Review is real work, and more of it is not automatically bad. The point is to choose it rather than discover it.

  • Batch it. Two review windows a day, one late morning and one mid-afternoon, cut down fragments without leaving teammates waiting long.
  • Ask for smaller changes. A large pull request is hard to review in one sitting, so it tends to come back to you several times.
  • Raise the load if it is lopsided. If you are the only reviewer for part of the codebase, your number is the start of a team conversation about sharing it.
  • Measure again. Change one thing, give it a week, and compare the rolls. How to tell if a productivity change actually worked covers doing this fairly.

For the wider picture of a developer’s day, see time tracking for developers.

Questions

Does Punchcard see which repositories or pull requests I review? No. It keeps the site name only, such as github.com, never the full address, path, search terms or page title.

Will my manager see this? No. There are no accounts, no team features and no cloud. Tracked data never leaves the Mac, and you share a receipt only if you choose to.

Does itemizing need Accessibility or Screen Recording permission? No. Punchcard needs neither. Itemizing uses the Automation permission, asked once per browser, and you can revoke it per browser in System Settings, Privacy and Security, Automation. Private, Incognito, InPrivate and Guest windows are never read.