In 2017 a group of researchers did the obvious thing nobody had properly done: they put monitoring software on the machines of 20 professional developers at four companies and watched what happened for 220 work days. Not a survey. Not a retrospective. Actual logged activity, categorized.
Coding came out at 21.0% of the workday.
I've seen that number used to argue that engineers are unproductive, which gets it exactly backwards. Those developers weren't wasting 79% of the day. They were doing the job. The mistake is thinking the job was ever mostly typing. There is a whole operational layer above coding is the smallest part of software engineering that XenGrowth's work on go-to-market systems documents.
What does the other 79% consist of?
Email at 14.5%. Work-related web browsing at 11.4%. Planned and unplanned meetings. Planning and work-item tracking. Reading and writing documents. And a long tail of things that resist categorization, which is itself informative.
The comparison that should stop you is this one: collaborative activities — meetings, ad-hoc conversations with co-workers, customers and managers, plus email — came to 24.4%. More than coding. The median engineer in that sample spent more of their day working through other people than working through an editor.
Activity | Share of workday | What it actually is |
|---|---|---|
Coding | 21.0% | Reading, editing and navigating code — note that reading is in here, not just writing |
Collaborative activities (total) | 24.4% | Planned meetings, ad-hoc meetings, email with colleagues, customers, managers |
14.5% | Counted inside the collaborative total above | |
Work-related web browsing | 11.4% | Documentation, Stack Overflow, vendor docs, issue trackers |
Code review | 1.3% | Formal review sessions only |
Version control | 0.7% | Reading, accepting and submitting changes |
Debugger use | 0.4% | Time inside an actual debugger, not debugging in general |
Two of those rows deserve a caveat rather than a headline. Debugger use at 0.4% does not mean engineers barely debug — it means most debugging happens by reading code, forming a hypothesis and adding a log line, all of which the tool logged as 'coding'. Same with code review at 1.3%: much review reading happens in a browser and lands in the browsing bucket. The categories are activities, not intentions. On the operations side of this specifically, The XenGrowth resource library is worth reading.
How fragmented is the day, really?
Badly. Outside planned meetings, developers stayed in a single activity for between 0.3 and 2.0 minutes before switching to another one. Planned meetings were the sole exception at 15.8 minutes, and the researchers noted that developers largely weren't using their computers during those anyway.
The most frequent pattern in their sequence analysis was a quick switch to email during a coding task. Not a break — a two-minute dip, mid-thought, and back.
The exception in the data is more encouraging than the average. One participant coded for 135.7 minutes with no break longer than two minutes. It is possible. It just isn't what the median day looks like.
This has a direct consequence for tooling that most tool marketing ignores. A day already chopped into two-minute pieces has very little room for a tool that saves thirty seconds of typing and adds a verification step. The saving lands inside a fragment; the verification cost lands wherever your attention next comes back to it, which may be twenty minutes and three context switches later.
Why do engineers think they code more than they do?
Ask an engineer what fraction of their week is coding and you will usually hear something between a third and a half. The measured figure is 21%. That gap is worth sitting with, because it is not carelessness — it is a predictable property of how memory works, and it recurs everywhere in this field.
Coding is the part of the day with a clear beginning, a clear end, and a visible artifact. You remember the two hours you spent getting a migration right. You do not remember the forty separate ninety-second interruptions, because none of them had a shape. Recall over-samples episodes with structure, so the structured minority of the day expands to fill the estimate.
The same mechanism explains the most-quoted finding in METR's randomized trial of AI coding tools, where experienced developers estimated they had been sped up 20% while measurement showed them 19% slower. In both cases people are reporting on the vivid part of the experience rather than the aggregate. The suggestion arriving instantly is memorable. The three minutes spent later working out why it was subtly wrong is not.
Which is a general warning about this whole topic. Almost every strong claim about developer productivity, in either direction, rests on somebody's impression of their own week. The two studies in this post are worth more than the impressions precisely because neither of them asked.
Where does maintenance fit?
Stripe's Developer Coefficient survey approached the question from the other end — asking rather than measuring, so treat it as softer evidence — and found that of an average 41.1-hour week, 13.5 hours went to addressing technical debt and another 3.8 to fixing bad code. That's 17.3 hours, roughly 42% of the week, spent on software that already exists. There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
Put the two studies side by side and a shape emerges. A minority of the day is coding. A large fraction of that coding is maintenance. Which means writing genuinely new code — the thing a code generator is best at — is a minority of a minority.
Task | Share of the job | How much AI actually helps |
|---|---|---|
Writing new code in a known pattern | A minority of the 21% | A lot. This is the case the demos show, and it is real |
Understanding code you didn't write | Inside coding and browsing | Some. Summarization helps; it also confidently misreads intent, and you cannot tell which from the output |
Deciding what to build at all | Inside the 24.4% collaborative | Almost none. The constraint is other people's disagreement, not generation speed |
Diagnosing a failure nobody has named | Spread across coding and browsing | Little. It needs system state and history the model cannot see |
Negotiating a requirement or a deadline | Inside the 24.4% collaborative | None that matters |
Paying down technical debt | ~13.5 hrs/week (Stripe) | Mixed. Generation is easy; knowing which debt is load-bearing is the hard part |
There is one honest objection to leaning on the Meyer study, and it is the study's age. It ran before the current generation of tooling, before remote work became the default, and on a sample of twenty people at four companies. A 2026 replication might well find coding higher, or lower, or the fragmentation worse now that chat has replaced some of that 14.5% email. What I would not expect it to find is coding as a majority of the day, because the activities crowding it out — deciding, explaining, waiting, reading — have not become less necessary since 2017. If anything the collaborative share has grown.
Isn't this just Amdahl's law?
It is, and stating it that way is the most useful thing in this post. Speed up one part of a system and your total gain is bounded by how much of the system that part was. If coding is 21% of the day and you make it infinitely fast, the day gets 21% shorter. That is the ceiling — before you subtract the verification cost.
And the verification cost is real. Stack Overflow's 2025 survey put AI adoption at 84% while trust in output accuracy fell to 29%, with the top-cited frustration being output that is 'almost right, but not quite' — which respondents said made debugging more time-consuming. Almost-right code moves work out of the writing bucket and into the comprehension bucket. Comprehension was already the expensive part. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
GitClear's commit analysis shows the same thing at the codebase level: copy-pasted lines up from 8.3% in 2020 to 12.3% in 2024, refactored lines down from 24.1% to 9.5%. More code, less organized. Every line of that is future 42%-of-the-week.
What should you actually do with this?
Stop optimizing the 21% first. If you want a faster week, the largest addressable block in the data is collaborative overhead and fragmentation, not typing speed. A meeting that shouldn't exist costs more than a slow autocomplete
Get honest about which 21% you're in. Writing new code in a known pattern is the part that got cheap. Reading unfamiliar code and diagnosing failures did not, and both sit in the same measured bucket
Treat 'almost right' as a cost, not a near-miss. Output that compiles and is subtly wrong converts cheap writing time into expensive comprehension time, and the conversion is invisible in any metric that counts lines shipped
Invest in the 24.4%. Writing a clear design doc, running a meeting that ends in a decision, disagreeing with a stakeholder without stalling the project — these were already the largest block of the job and are the least automatable part of it
Measure fragmentation before you measure output. If your activity switches are running at the study's rate, no tool is going to fix that, because the tool is being used inside the same two-minute windows
None of this is an argument that coding doesn't matter. You cannot do the other 79% well without it — the reason senior engineers are worth listening to in the 24.4% is precisely that they have spent years in the 21%. Judgment about systems is downstream of having built some.
But if someone tells you a coding assistant made their team twice as productive, the arithmetic says they are either measuring the wrong thing or they had an unusual day. The ceiling is 21%, minus whatever the verification costs, and the verification is not free.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on coding is the smallest part of software engineering inside a commercial team? the XenGrowth practice publishes operator guides on the revenue side of this work.
Five questions on the measured numbers in this post. The research is more counterintuitive than the summary makes it sound, and the explanations are where the useful part is.
