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.
Why This Question Is Hard to Answer
Most "developer productivity" numbers online are self-reported. The problem? Research published in the Journal of Biomedical Informatics found that self-reported work hours are inflated by 10-20% compared to observed hours. Developers are no exception: context switching, debugging, and "thinking time" feel like coding.
IDE heartbeat data solves this. Every few minutes, the editor sends a signal confirming the developer is actively writing or editing code. No self-reporting. No guesswork. Just timestamps.
Here's what real coding activity looks like when measured through IDE heartbeats — an activity heatmap from PanDev Metrics showing coding sessions across two weeks, broken down by hour:
Activity heatmap — yellow blocks are coding sessions, gaps are meetings.
Each colored block represents an active coding session. The pattern is immediately visible: most coding happens between 9 AM and 6 PM, with noticeable gaps during lunch and meeting-heavy hours. Some late-night sessions appear, but they're rare.
What the Data Shows
Median: 78 minutes per day
| Metric | Value |
|---|---|
| Median coding time per day | 78 min (1h 18m) |
| Mean coding time per day | 111 min (1h 51m) |
| Minimum (among regular coders) | ~10 min |
| Maximum | ~280 min (4h 40m) |
The median is 30% lower than the mean, a classic sign of right-skewed distribution. A few power coders pull the average up. For benchmarking, always use the median.
This aligns closely with external research. A 2022 paper by Xia et al. in IEEE Transactions on Software Engineering found that developers spend an average of 52 minutes per day in active coding sessions, with significant variation based on role and project phase. These numbers also have implications for delivery performance metrics like DORA — understanding actual coding time is the first step to optimizing your pipeline.
Distribution: the 1-2 hour sweet spot
| Daily coding time | Share |
|---|---|
| Under 30 min | ~12% |
| 30-60 min | ~21% |
| 1-2 hours | ~32% |
| 2-3 hours | ~9% |
| 3-4 hours | ~21% |
| 4+ hours | ~6% |
The largest group codes 1-2 hours per day. Over half fall between 30 minutes and 2 hours. The "mythical 8-hour coder" doesn't exist in any dataset we've seen, academic or commercial.
This distribution matches findings from the SPACE framework paper (Forsgren et al., 2021) which argues that developer productivity cannot be reduced to a single dimension like coding time.
Tuesday is the most productive day
| Day | Activity level |
|---|---|
| Monday | High |
| Tuesday | Peak |
| Wednesday | High |
| Thursday | Medium-High |
| Friday | Medium |
| Saturday | Low |
| Sunday | Minimal |
Tuesday consistently leads in aggregate coding activity across companies of different sizes and industries. Friday shows a noticeable dip, and weekend coding runs at roughly 3-4x lower volume than weekdays.
Similar patterns appear in GitHub's analysis of commit timestamps across millions of repositories: Tuesday and Wednesday dominate global commit activity.
VS Code leads, Cursor is the fastest-growing
| IDE | Market position |
|---|---|
| VS Code | Dominant |
| Cursor | Fastest-growing (AI-first) |
| JetBrains (IntelliJ, PhpStorm, WebStorm) | Strong in Java/PHP ecosystems |
| Visual Studio | Enterprise / .NET |
The 2024 Stack Overflow Developer Survey confirmed VS Code as the most popular IDE at 73.6%. Our data shows a similar pattern, with Cursor emerging as a significant new player, reflecting the rapid adoption of AI-assisted development tools. For a deeper analysis of how IDE choice affects developer workflows, see our IDE landscape breakdown for 2026.
Java and TypeScript dominate actual coding time
| Language | Position |
|---|---|
| Java | Leading |
| TypeScript (including TSX) | Close second |
| Python | Third |
| PHP | Significant |
| Kotlin, Dart, C# | Notable presence |
| YAML | Top 10 |
The presence of YAML in the top 10 reflects modern development reality. Infrastructure-as-code, CI/CD configs, and Kubernetes manifests consume meaningful engineering time. The 2023 CNCF Survey found that 84% of organizations use or evaluate Kubernetes, which explains the YAML investment.
What This Means for Engineering Leaders
1. Stop expecting 6-8 hours of coding
Pure coding time of 1-2 hours per day is normal and healthy. The remaining time goes to code reviews, architecture discussions, debugging, documentation, and context switching.
As Cal Newport argues in Deep Work, the capacity for focused creative work is limited to roughly 4 hours per day, and that's the upper bound. Most knowledge workers operate well below that.
2. Protect Focus Time over total hours
Developers who code 3-4 hours daily likely have fewer interruptions, not more talent. Research by Gloria Mark at UC Irvine found that it takes an average of 23 minutes to refocus after an interruption. A developer with three meetings scattered throughout the day may have zero effective focus blocks.
PanDev Metrics tracks Focus Time as a percentage of total activity — the higher the percentage, the fewer interruptions a developer experienced. In the dashboard below, you can see real-time activity across the entire team:
PanDev Metrics dashboard showing real-time team activity, online employees, and project status.*Actionable*: Reduce meetings on Tuesdays and Wednesdays when coding momentum peaks. Establish "focus hours" with no meetings.
3. Use median for team benchmarking
The mean (111 min) is misleading because outliers skew it. Median (78 min) is your honest benchmark. If your team is in this range, they're performing normally. If significantly lower, investigate meeting culture before questioning motivation.
4. Measure, don't guess
Self-reported time tracking is consistently inaccurate. IDE heartbeat data captures actual editor focus, providing ground truth instead of perception. This matters especially for remote teams where visibility is lower.
"As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple."
— Maksim Popov, CTO ABR Tech (Forbes Kazakhstan, April 2026)
Methodology
This analysis uses anonymized, aggregated IDE heartbeat data from PanDev Metrics. We filtered for B2B engineering teams with consistent activity over a 90-day window. All data represents pure coding activity (editor focus), excluding idle time, browser activity, and meetings. No individual or company-identifying data was exposed.
Our findings are consistent with published academic research on developer work patterns, including studies from Microsoft Research, IEEE, and the SPACE framework.
Want to understand your team's real coding patterns? PanDev Metrics tracks IDE activity with second-level precision across VS Code, JetBrains, and 8 more editors. Free to start.
More from PanDev Metrics Blog
- DORA Metrics: The Complete Guide (2026)
- 10 Engineering Metrics Every Manager Should Track
- Focus Time: Why 2 Hours = 6 Hours Fragmented
- 5 Data Patterns That Scream Burnout
- IDE War 2026: VS Code vs JetBrains vs Cursor
PanDev Metrics — Engineering Intelligence platform. Track real coding time across VS Code, JetBrains, and 8 more editors.
Top comments (0)