Some developers swear by 6 AM starts with coffee and silence. Others don't open their IDE until 10 PM. Managers debate whether to enforce "core hours" or let people work whenever they want.

We looked at extensive activity data from developers across 100+ B2B companies to find out when developers actually code — and whether timing matters.

Every engineering manager has a gut feeling about their team's weekly rhythm. Monday feels slow. Friday feels like a wind-down. But what does the data actually show?

We analyzed thousands of coding hours from developers across 100+ B2B companies to map developer productivity across the work week — and the results challenge some common assumptions.

The IDE debate is eternal. VS Code fans say it's fast and extensible. JetBrains loyalists swear by deep language support. And now Cursor is the new challenger, riding the AI wave. The Stack Overflow Developer Survey consistently ranks VS Code as the most popular editor, while the JetBrains Developer Ecosystem Survey shows strong loyalty among its users. But surveys measure sentiment, not reality.

What do developers actually use when they sit down to work? Not what they tweet about. Not what they starred on GitHub. What they code in, hour after hour, day after day.

We have the data. thousands of hours of tracked coding time across 100+ B2B companies, broken down by IDE.

"Adding manpower to a late software project makes it later." Fred Brooks wrote that in 1975. Fifty years later, engineering leaders still debate whether it's true.

We looked at real coding data from 100+ B2B companies on PanDev Metrics to understand how team size relates to individual developer productivity. The answer is more nuanced than Brooks suggested — but his core insight still holds.

AI coding assistants went from novelty to necessity in under three years. GitHub Copilot, Cursor, Cody, and dozens of alternatives now sit inside developers' editors, suggesting code, answering questions, and writing boilerplate. A Deloitte report on AI adoption in software development estimates that ~70% of enterprise development teams now use some form of AI coding assistance.

But are they actually making developers more productive? Or just more reliant on autocomplete?

We looked at real IDE usage data from 100+ B2B companies to find out what AI-assisted coding looks like in practice.

You've just hired a senior developer. They start Monday. When will they be fully productive?

HR says "30 days." The hiring manager says "a few weeks." The developer themselves says "give me the codebase and I'll be fine."

Reality is different. Coding activity data tells a more honest story about what new developer ramp-up actually looks like — and it's longer than most organizations plan for.

Every CTO has had this conversation. You walk into the CEO's office and say, "We need to spend the next quarter refactoring." The CEO asks, "What's the business value?" You struggle to answer in terms that don't involve the words "architecture," "coupling," or "dependency injection." The DORA State of DevOps Reports consistently find that teams burdened by technical debt deploy ~50% less frequently and have ~2-3x higher change failure rates.

The CEO isn't wrong to ask. They're not anti-engineering. They just need to understand the investment in business terms. And that's where most CTOs fail — not because they're bad communicators, but because they don't have the right data.

Here's how to fix that.

Add XP, levels, and badges to a developer platform and you'll get two reactions. Some developers light up — they check their progress daily, compete on leaderboards, and proudly display badges on their GitHub profiles. Others recoil — they see it as surveillance dressed up in game mechanics, an infantilizing system that reduces their craft to a score.

Both reactions are valid. The question isn't whether gamification works in absolute terms. It's when, how, and for whom.

The most common fear engineers have about activity tracking is simple: "My manager will use this data against me."

They're not wrong to worry. Many organizations have implemented "productivity metrics" as a stick — identifying who codes the least, who commits the fewest lines, who logs the shortest hours. The result is predictable: developers game the metrics, resentment builds, top performers leave, and the remaining team optimizes for looking busy rather than being effective.

There's a better way. Data can be a tool for positive reinforcement — and it's far more effective.

Developer Experience — DevEx or DX — has gone from a niche concept to a boardroom topic. Companies like Google, Spotify, and Shopify have dedicated DevEx teams. Job postings for "Developer Experience Engineer" have tripled since 2023. The JetBrains Developer Ecosystem Survey now includes DevEx-specific questions, signaling that the industry treats this as a measurable dimension, not a buzzword.

But what is Developer Experience? How do you measure something that feels inherently subjective? And why should a VP of Engineering care?