Developers Spend Just 1% of Coding Time Using VS Code's Debugger (11,805 Sessions Analyzed)
Analysis of 11,805 coding sessions from 68 developers tracked over 3 months. Developers spend just 1.4% of their time using VS Code's debugger - most rely on console.log statements instead.
Research Summary
- • 68 developers tracked over 3 months (July-October 2025)
- • 11,805 coding sessions (30-minute intervals) averaging 18 minutes of active coding each
- • 3,526 hours of active coding time analyzed (excluding idle time)
- • All data collected via FlouState automatic tracking
My Personal Wake-Up Call
Building FlouState solo meant debugging felt like half the job. Those late-night sessions hunting down edge cases were exhausting - terminal full of `console.log()` statements, manually reproducing bugs, reading stack traces.
After 3 months (203 hours tracked), I looked at my own data and saw something surprising:
My Personal Breakdown (3 Months)
203 hours tracked, 649 coding sessions
0.2% debugging = 20 minutes over 3 months
I spent 0.2% of my time using VS Code's debugger.
That's 20 minutes over 3 months of active coding.
The Reality:
Debugging felt exhausting and time-consuming. But the data showed I was mostly creating (56.6%) and exploring code (25.8%). The "debugging" I remembered was actually print statements scattered throughout normal development.
VS Code has a world-class debugger built in. I used it for 20 minutes in 3 months.
This Isn't Just Me. It's All of Us.
I analyzed 68 FlouState users who've been tracking since July 2025. The pattern was universal: we avoid VS Code's debugger like it's radioactive.
Debugger Usage Across 68 Developers:
46.2%
Writing code (includes console.log debugging)
28.7%
Reading code (includes stack trace hunting)
23.7%
Refactoring (includes removing debug logs)
1.4%
Using VS Code debugger (breakpoints, step-through)
Work Type Distribution (68 Developers)
Based on 11,805 coding sessions, 3,526 hours tracked
Real data from 68 FlouState users since July 2025
📊 Understanding the Numbers
Across 3,526 hours of tracked coding time, developers spent an average (mean) of 13 minutes per month using VS Code's debugger. Not per day. Per month.
The median was 0 minutes - most developers never used it at all. Even among the 25% who used it at least once, the average was only 54 minutes per month.
📊 Distribution Analysis:
Here's how debugger usage breaks down across all developers:
- • 75% of developers never used the debugger - not even once
- • 10% of developers used it less than 1% of their time
- • 15% of developers used it 1%+ of their time (highest: 52%)
Median usage: 0%. Even with 9 developers using it 2%+, the average is still only 1.4%.
Important Clarification:
This 1% measures active debugger UI usage (breakpoints, watches, step-through). It does NOT include console.log() debugging, reading error logs, or manual bug reproduction - which likely account for a significant portion of actual coding time.
The gap reveals how we debug, not how much we debug.
Why Do Developers Avoid the Debugger?
If VS Code's debugger is so powerful, why do developers use it <1% of the time?
Here's the thing: console.log() has its place - quick sanity checks, debugging async/promise chains, production logging. But for complex state issues, race conditions, or stepping through multi-layer logic, the debugger is often more efficient.
Common Print Debugging Workflow:
1. Add `console.log("here")` → Save file → Reload browser → Check console → Repeat 10x
2. Forget to remove logs → Ship to production → Pollute user consoles (or strip them with build tools)
3. Can't inspect variables mid-execution → Add more logs → Cluttered code
4. Race conditions hard to diagnose → Guess at timing → Takes longer
This works fine for many bugs, but complex issues can take longer with this approach
Why Developers Prefer console.log()
The strong preference for console.log() isn't laziness. It's psychology.
Immediate Gratification
Type `console.log("here")` → See output in 3 seconds. Setting up a debugger configuration? That could take 10 minutes. Our brains choose the dopamine hit of instant feedback.
Familiarity Bias
You learned console.log() on day 1 of coding. You've used it thousands of times. The debugger? Maybe never. We default to familiar tools even when better ones exist.
Sunk Cost Fallacy
You've already added 5 console.logs. "Might as well add one more" instead of switching to the debugger. 30 minutes later, you're still adding logs.
Perceived Complexity
"The debugger looks complicated" → Never learn it → Miss out on a potentially useful tool. Classic catch-22.
The Hidden Costs (That May or May Not Matter to You)
Some developers argue that never learning the debugger has costs. Others say console.log() works fine. Here are the arguments on both sides:
Time Investment Tradeoff
Pro-Debugger: Learning the debugger takes 2 hours upfront but may save minutes per bug.
Pro-Console.log: Console.log is instant and requires zero setup time.
Code Cleanup
Pro-Debugger: No leftover logs to remove.
Pro-Console.log: Modern linters catch leftover logs automatically.
Production Safety
Pro-Debugger: Can't accidentally ship debug logs with sensitive data.
Pro-Console.log: Modern build tools strip console.logs in production anyway.
Ultimately, if console.log() works for you and you're shipping products, keep using it. But knowing the debugger gives you options when console.log isn't enough.
The Opportunity Cost:
Investing just 2 hours learning VS Code's debugger can save hours every week by reducing debugging cycles and eliminating context-switching overhead. Yet most developers never make that investment.
What We're Missing: The Console.log Loop
Most debugging happens without the debugger. We add print statements, reload, check output, repeat. Based on my own patterns, I estimate this accounts for roughly 15-20% of actual coding time - but it's scattered across "Creating" (adding logs) and "Exploring" (reading output), making it invisible in aggregate statistics.
What If You Used the Debugger Instead?
For example, a bug that might take 10 console.logs and 30 minutes could potentially be solved with 1 breakpoint and 5 minutes. The debugger lets you pause execution, inspect all variables at once, and step through logic without modifying code.
New to the debugger? Start with this official guide (includes a 13-minute video walkthrough).
Methodology: How We Collected This Data
This research is based on FlouState's automatic tracking system, which categorizes developer work into 4 types:
Creating (46.2%):
Primarily adding new code with minimal deletions. This included console.log() debugging since it adds lines of code.
Exploring (28.7%):
Many file views with few edits - reading and understanding codebases. This included reading console.log() output and stack traces.
Maintenance (23.7%):
Balanced mix of additions and deletions - restructuring existing code. This included removing console.log() statements.
Debugger Usage (1.4%):
Active VS Code debugger UI usage only (breakpoints, step-through, watch variables). This does NOT capture console.log() debugging or other debugging methods.
Critical Note on Data Interpretation:
The 1.4% "Debugging" stat measures debugger tool usage, not total debugging time. Most debugging happens via console.log(), which is counted as "Creating" or "Exploring" depending on context.
Study Limitations
This analysis is based on FlouState users (n=68). Results may differ for enterprise development teams, users of other IDEs (JetBrains, Visual Studio), or developers working in different programming paradigms.
The study focuses on VS Code users specifically and may not represent debugging patterns across all development environments. However, VS Code's dominant market position (75.9% of developers according to Stack Overflow 2025 Survey) suggests these findings are broadly applicable to the industry.
All data collection happens locally in VS Code. Only aggregated 30-minute summaries are sent to the cloud - never your actual code content.
Privacy & Data Use:
This research uses anonymized aggregate data from 68 FlouState users. All data is fully anonymized - no individual developers, projects, or specific code patterns can be identified. Only aggregate statistics (percentages, totals, averages) are analyzed.
Your code content is NEVER captured by FlouState, only metadata like timestamps, file counts, language types, and branch names. Users can opt out of research participation anytime in Settings.
The Bottom Line
Developers spend just 1.4% of their time using VS Code's debugger.
The data shows we rely heavily on console.log() and manual debugging instead of built-in tools. Whether this is actually inefficient or just how developers prefer to work remains an open question.
The debugger exists. Most developers don't use it.
How this data was collected:
I built FlouState, a VS Code extension that automatically tracks coding activity. It records 30-minute intervals and tracks when the VS Code debugger is active vs inactive.
This analysis covers 68 developers, 11,805 coding sessions, and 3,526 hours of active coding time between July 14 - October 18, 2025.
Important caveats: This only tracks the VS Code debugger. It doesn't capture console.log, print statements, or external debuggers (gdb, lldb, etc.). So real "debugging" time is higher - but debugger tool usage is still remarkably low.