Every engineering leader asks the same question: how much time do developers actually spend writing code?
Microsoft Research found that developers spend only 30-40% of their time writing code. A 2019 study by Haystack Analytics suggested closer to 2 hours. Our own IDE heartbeat data across B2B engineering teams confirms a median of 78 minutes per day.
Here's what the data actually shows and why it matters.
McKinsey's 2023 developer productivity report found that engineers spend only 25-30% of their time writing code. The rest vanishes into meetings, context switching, and waiting. If you're an Engineering Manager relying on gut feeling, you're blind to where 70% of your team's capacity actually goes.
Here are 10 metrics that will sharpen your decisions. No fluff, no "track everything" advice — just the ones that separate informed management from guesswork.
Gloria Mark's research at UC Irvine found that it takes an average of 23 minutes and 15 seconds to refocus after a single interruption. Now consider a typical developer morning: 9:07 Slack pings, 9:15 standup reminder, 9:45 a "quick question" from a PM. By 10:30, they've been "working" for 90 minutes but written exactly 11 lines of code. Three interruptions consumed roughly 70 minutes of cognitive recovery time.
This isn't a productivity problem. It's a focus time problem. And the data shows it's costing your team far more than you think.
Fred Brooks warned in The Mythical Man-Month (1975) that measuring programmer productivity by volume of code is a trap: adding more code isn't the same as adding more value. Fifty years later, some organizations still equate lines written with work done. The SPACE framework (Forsgren et al., 2021) explicitly cautions against single-dimensional activity metrics — yet the need they address is real: how do you measure whether your engineering team is delivering?
The answer isn't another vanity metric. It's a composite signal we call the Delivery Index.
The "10x developer" is one of the most persistent myths in our industry — and one of the most damaging. Fred Brooks observed in The Mythical Man-Month (1975) that individual programmer productivity varies widely, but he also warned against the conclusion that hiring solves systemic problems. The SPACE framework (Forsgren et al., 2021) goes further: measuring individual developer "productivity" with a single metric is not just inaccurate, it's counterproductive.
We have data from B2B engineering teams and thousands of hours of tracked coding time. Here's what it actually says about developer performance variance — and why the answer matters less than you think.
Your senior developer is assigned to three projects. You assume they're giving each project a third of their time. Gerald Weinberg calculated the real math in Quality Software Management (1992): with three concurrent projects, each project gets about 20% of a developer's time — and the remaining 40% evaporates into context switching overhead.
This isn't speculation. It's a well-documented cognitive phenomenon, confirmed by our platform data across B2B engineering teams and consistent with Gloria Mark's research at UC Irvine showing 23 minutes of recovery time per interruption. Context switching is one of the most expensive invisible costs in software engineering.
According to McKinsey's research on developer productivity, software engineers spend only 25-30% of their time actually writing code. So where developers work should matter far less than how their time is structured. Yet the remote vs. office debate has been running for six years, with CEOs citing "collaboration" and developers citing "focus" — both arguing from conviction, not evidence.
We have thousands of hours of tracked IDE activity across 100+ B2B companies. The data tells a more nuanced story than either side wants to hear.
Gallup research consistently shows that manager quality is the single largest factor in employee engagement — yet most engineering managers run 1:1s the same way: "How are things going?" followed by an awkward silence, then a pivot to project status updates. That's not a 1:1 — that's a standup with extra steps. Real 1:1s should be the most valuable 30 minutes in your developer's week, and data makes them dramatically better.
Commits and pull requests tell you what was delivered. But they miss the hours of debugging, refactoring, and research that happen between pushes. IDE plugins capture that missing layer — how much time was spent coding, which files were touched, and when developers were most active.
PanDev Metrics offers plugins for VS Code, JetBrains (IntelliJ, PhpStorm, WebStorm), Eclipse, Xcode, Visual Studio, PL/SQL Developer, a Chrome extension, and a CLI for everything else. This guide covers installation and configuration for all of them.
WakaTime is one of the most well-known developer time tracking tools, with over 500K users, 40+ IDE plugins, and an annual "Yearly Wrapped" report that has become a community tradition. At $9/month for the Premium plan, it is one of the best values in developer tooling. PanDev Metrics is an Engineering Intelligence platform built for teams and organizations. They both track coding activity via IDE plugins — but that is where the similarity ends.
If you are evaluating both tools, this comparison will help you understand which one fits your needs.