18 posts tagged with "data"

A VP of Engineering at a 300-person company asked me a direct question: "We're debating a sabbatical policy. HR says it boosts retention. Finance says it costs 2 months of output per taker. Who's right?" The data we could pull answered it: both, but the effect sizes are different. Returning developers hit full output in 4-6 weeks (not 8-12 as commonly assumed), and 90-day retention for post-sabbatical engineers is measurably higher than their pre-sabbatical cohort. The surprise is that the commit quality on the ramp-up weeks is better than baseline, not worse.

The Society for Human Resource Management's 2023 Employee Benefits Survey shows 22% of US employers now offer formal sabbatical programs, up from 13% in 2018. Among tech companies the rate jumps to roughly 34% — driven partly by retention competition and partly by the post-2022 burnout reckoning. But most of the published data on sabbatical ROI comes from self-report surveys. Our IDE telemetry gives us something those surveys can't: what actually happens on the keyboard week-by-week when someone comes back.

Ask 100 engineers about rubber duck debugging and 98 will nod knowingly. Ask them for evidence it works and most will cite The Pragmatic Programmer (1999). We can do better than 26-year-old folklore. Across 2,100 debugging sessions we instrumented in 2025, engineers who verbally narrated the bug to a colleague, an inanimate object, or into a voice recorder solved it in 31 minutes median — compared to 48 minutes for silent debugging. A 35% reduction. The psychology research calls this the self-explanation effect (Chi et al., 1989), and it has 30+ years of replication in education research.

But the effect isn't uniform across bug types. For some classes of bugs, verbalization helps 42% of the time and does nothing 58% of the time. This article breaks down what our IDE data shows about when the duck earns its keep and when it's a ritual masquerading as technique.

The Pomodoro Technique says work for 25 minutes, break for 5, repeat. Francesco Cirillo invented it in the late 1980s for studying. Not for coding. Not for the kind of flow-state work engineers do. We looked at IDE heartbeat patterns from engineers who self-identify as Pomodoro users versus engineers who don't, and the results are uncomfortable for the method: strict 25/5 Pomodoro users averaged 42 minutes of actual focused coding per day. Engineers who ignored the timer averaged 2 hours 12 minutes. The timer was, for most of them, a scheduled interruption engine.

This isn't an anti-Pomodoro article. It's a data-driven look at why 25 minutes is the wrong interval for coding work and what intervals actually match how engineers flow. Cal Newport's Deep Work already argued this conceptually. What we can add is telemetry — our IDE data shows the specific breakpoints where coding sessions do and don't recover from interruption. The Pomodoro format interrupts right at the wrong place.

A distributed team with 5 hours of timezone spread has a median lead time of 6.8 days per change. A colocated team in the same codebase — same language, same size, same PR size — has a median lead time of 3.2 days. That's not a rounding error. That's the timezone tax, and it roughly doubles at every additional 3-4 hours of spread. GitLab's 2023 remote-work report estimated "3-5 hours of overlap" as the sweet spot for async-friendly teams, and our IDE-heartbeat data across 100+ B2B companies says the same — but with the extra detail of where exactly the time goes.

This isn't an article about whether remote work is good (it is, for many teams). It's about the specific ways that timezone spread slows delivery, and what measurements tell you whether your distributed team is paying a 2× lead-time penalty or learning to live with it.

In our IDE dataset of 100+ B2B companies, engineers on AdTech platforms ship 38% fewer pull requests per month than engineers in SaaS tooling — and produce more customer revenue per head. Meanwhile The Trade Desk disclosed it processes over 13 million ad requests per second. Scale like that reshapes what "productive" means. A PR count that would look alarming in a consumer app is perfectly normal when a single configuration line is deployed across 10 million QPS.

AdTech engineering is different, and measuring it with generic DORA-only dashboards misses the point. This article lays out what data-heavy teams actually spend time on, what the numbers look like across the 14 AdTech companies in our dataset, and which productivity signals matter more than throughput for real-time bidding, attribution, and ad-server work.

The median tenure of a software engineer at a B2B company is 2.3 years (Stack Overflow 2025 Developer Survey). The median surprise of the engineer's manager when they resign is… also high. We matched IDE heartbeat data, Git activity, and task-tracker signals against 43 confirmed engineer resignations across 11 PanDev Metrics customer teams in 2025. Seven behavioural patterns showed up in the data 30-90 days before the resignation letter.

One of them is almost never on the standard "burnout signal" list. That's the one this post exists for.

Your 40-engineer team maintains 34 repositories. Sound reasonable? We see this shape often. A typical developer in that configuration triggers 11.4 context switches per day between repositories — almost all invisible to the EM, each costing roughly 23 minutes of refocus time, per UC Irvine's Gloria Mark (The Cost of Interrupted Work, 2008) and subsequent replications. The same team post-monorepo migration: 3.2 switches per day. The productivity math is obvious; the cost math is where it gets interesting.

Both architectures work. Google runs the largest known monorepo (2 billion+ lines of code, ~85,000 engineers). Netflix runs thousands of polyrepos. The question isn't which is better in the abstract — it's which fits your team size, your CI budget, and your tolerance for coordination overhead.

Copilot wrote 420 tests for your payments module in two days. Coverage went from 58% to 84%. Release confidence? Unchanged, maybe worse. A 2024 IEEE study (An Empirical Study on the Usage of Transformer Models for Code Completion, Ciniselli et al.) found LLM-generated tests pass the compiler 92% of the time but catch only 58-62% of injected mutations — the standard research test for "does this test actually verify anything." Human-written tests in the same study scored 78%. The ~20-percentage-point gap in mutation score is the real AI test quality story, not the coverage number everyone reports.

This piece measures what AI-generated tests are good at, what they miss, and how to structure your pipeline so AI adds throughput without eroding release confidence.

AI code review sits at the crest of the hype cycle. GitHub Copilot, CodeRabbit, Qodo, Graphite, and half a dozen startups are pitching a future where LLMs catch bugs faster than humans. Microsoft Research and Bacchelli's seminal 2013 study on code review established the baseline we've been measuring against for a decade: human review catches ~14% of functional defects but 68% of maintainability issues. The question now is: does layering an LLM on top actually move either number?

We pulled review data from 100 B2B teams between Q1 2025 and Q1 2026: a mix of teams using AI review, teams not, and teams running hybrid. The pattern isn't what the vendors claim.

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.