{"slug": "the-unexpected-things-developer-metrics-can-measure", "title": "The unexpected things developer metrics can measure", "summary": "Developer-experience metrics built by DX to evaluate developer tools have revealed that Daylight Saving Time shifts engineering behavior: across three years of data, active coding time in Seattle increased by roughly 6% and pull requests completed about 8% faster when DST begins, compared to developers closer to the equator. Brian Houck, who reported the finding, argues that such metrics measure the overall experience of software engineering, not just interventions like AI assistants or build systems, and can explain outcomes from office design to time changes.", "body_md": "# The unexpected things developer metrics can measure\n\n### We built metrics to evaluate developer tools. They turned out to explain everything from office design to Daylight Saving Time.\n\n**Welcome to the latest issue of Engineering Enablement**, a weekly newsletter sharing research and perspectives on developer productivity.\n\nDX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. [Read the full report.](https://getdx.com/resources/?utm_source=newsletter)\n\n*A quick heads-up: this issue is a little different from our usual format. Instead of sharing a finding from our research and conversations, this issue is more of a reframe of how to think about what developer metrics are actually for.*\n\nHere is a sentence I never expected to write: Developer-experience metrics can measure the impact of Daylight Saving Time.\n\nNot a survey asking developers how they feel about the time change. An actual, measurable shift in engineering behavior, detected using the same kinds of outcome metrics we use to evaluate AI coding assistants, build systems, and code review workflows.\n\nThat sounds like an absurd thing to measure. And yet, [that’s exactly what we found](https://www.linkedin.com/posts/brianhouck_developerexperience-daylightsavingtime-productivity-activity-7305671070206869504-VNgj?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAbL-CEB_GIa71OGfWkh-nZOd86fsAhsAZc).\n\nWhen Daylight Saving Time begins, developers in Seattle (one of the highest-latitude major cities in the continental United States) show a measurable shift relative to developers closer to the equator, where seasonal daylight changes are much smaller. Across three years of data, active coding time increased by roughly 6%, while pull requests completed about 8% faster, driven largely by quicker code reviews.\n\nThe most plausible explanation is also the simplest: an extra hour of evening daylight appears to keep people engaged with their work a little longer.\n\nI’d resist reading that as purely good news. More engagement isn’t automatically healthier. If some of that extra time is coming at the expense of sleep or recovery, that’s a trade-off worth measuring, not celebrating.\n\nAt first glance, this has nothing to do with software engineering. After all, developer metrics are supposed to measure developer things: faster builds, better IDEs, improved code reviews, AI-assisted coding.\n\nOr so I thought.\n\nThe more I’ve worked with developer-experience metrics, the more I’ve come to believe we’ve been thinking about them too narrowly. We often describe them as a way to evaluate developer tools and engineering workflows. But that’s not really what they’re measuring. They’re measuring the experience of doing software engineering. And that experience is shaped by far more than software.\n\n### Measuring outcomes, not interventions\n\nWhen people think about developer-experience metrics, they naturally think about the interventions we introduce: a new AI coding assistant, a faster build system, a different code review process, a new deployment pipeline.\n\nBut those aren’t actually what the metrics care about.\n\nGood developer-experience metrics measure outcomes. They tell us whether developers are able to do focused, meaningful, high-quality work. Once you measure outcomes instead of interventions, something interesting happens.\n\nThe intervention no longer has to be software. It can be an office redesign. A meeting policy. The weather. Even Daylight Saving Time.\n\nThat doesn’t mean engineering leaders suddenly own the weather, facilities, or company policy. But measurement doesn’t have to imply ownership. Sometimes it helps explain why an outcome changed. Other times it gives you evidence to influence the people who *do* own the lever.\n\nThat realization changed how I think about developer metrics. They’re still excellent for evaluating developer tools. They just turn out to be useful for much more.\n\nOnce I started looking through this lens, examples kept appearing, not just in my own research, but across entirely different disciplines. And they weren’t limited to software engineering. Researchers have found that [higher indoor air pollution](https://docs.iza.org/dp12632.pdf) correlates to more errors by chess players, [warmer classrooms](https://www.aeaweb.org/articles?id=10.1257/pol.20180612) are associated with lower student performance, and [high-noise environments](https://www.sciencedirect.com/science/article/abs/pii/S0272494411000429) measurably degrade memory and motivation. Different domains, different outcomes, but the same underlying lesson: our environment shapes performance.\n\nThe difference is that developer-experience metrics give us a language for asking the same kinds of questions about software engineering.\n\nSome of those influences are things organizations can change. Others aren’t. Both leave measurable fingerprints on the developer experience.\n\n### The spaces your developers work in\n\nDaylight Saving Time is an unusual example because there isn’t much an engineering leader can do about it. Office space is different. Organizations make decisions about where and how developers work all the time, yet those decisions are often driven by cost, convenience, or intuition rather than evidence.\n\n[When we asked developers](https://www.microsoft.com/en-us/research/publication/the-best-of-both-worlds-unlocking-the-potential-of-hybrid-work-for-software-engineers/) what they actually value about coming into the office, the answers were overwhelmingly human. The top response, by a wide margin, was other people: seeing colleagues face to face, the conversations that get sparked, the camaraderie. Office design came next (whiteboards, rooms to hash out problems), followed by food and coffee. This isn’t just a list of office perks. It’s a window into the parts of the developer experience that still depend on the physical world.\n\nThe specifics ranged from the practical to the personal. One developer’s entire reason for coming in: “I don’t have to fight with my cats.” However they phrased it, the pattern was the same. What draws developers to the office is overwhelmingly human, and largely physical, the parts of the experience that software still hasn’t managed to replace.\n\nThose findings explain *why* the office matters. Developer metrics can help answer the next question: **how much does it matter?**\n\nIn a previously unpublished analysis, I looked at teams relocating between office spaces. The building itself moved the numbers.\n\nOne team relocated into a well-designed, high-performance office and saw developer engagement, measured through active coding time, increase by roughly 13% relative to comparable peer teams. The really interesting part came later. When that same team eventually moved back into their original office, their active coding time returned almost exactly to its previous level.\n\nI also saw the opposite pattern. Teams moving into poorly designed office spaces experienced productivity declines on the order of 10%.\n\nThis is observational, not a controlled experiment, so we should be cautious about claiming causality. Office moves often coincide with organizational changes, new teammates, and countless other confounding factors. But the pattern is still striking. The same outcome metrics we might use to evaluate a new AI coding assistant also measured the impact of an office redesign. The intervention changed. The measurement didn’t.\n\nThat changes the conversation. Office space is usually treated as a facilities expense to be minimized. But if a better workspace meaningfully improves the developer experience, it becomes a productivity investment instead. A useful rule of thumb is that facilities costs are roughly 10% of payroll. That means an improvement in developer effectiveness on the order of 10% has the potential to offset the entire cost of the workspace, before considering any additional benefits such as hiring, retention, or collaboration.\n\nInterestingly, our earlier hybrid-work research found another version of the same idea. Developers who chose whether to work from home or the office based on the type of work they planned to do reported higher productivity than those choosing primarily for personal convenience. Different environments appear to support different kinds of work, and developer metrics give us a way to test those assumptions rather than simply debate them.\n\n### When the weather is a variable\n\nDaylight Saving Time at least has policy debates attached to it. Weather is even simpler. No engineering leader can change it.\n\nAnd yet [it still shows up in the data](https://queue.acm.org/detail.cfm?id=3819080).\n\nIn Seattle, you can often identify winter snow days simply by looking at engineering activity. Active coding time drops by roughly 18%. The reasons are easy to imagine: disrupted commutes, childcare, school closures, or simply the irresistible pull of a rare Pacific Northwest snow day. Untangling those mechanisms is difficult, and I wouldn’t claim a clean causal story.\n\nBut the mechanism isn’t really the point.\n\nThe point is that the measurement detected the change.\n\nAt first glance, measuring something you can’t control might seem pointless. I think the opposite is true. If a team’s delivery slows during a snowstorm, that isn’t necessarily a performance problem to solve. It’s the context that helps explain what happened.\n\nThat’s one of the underappreciated benefits of developer-experience metrics. Sometimes their greatest value isn’t telling you what to change. It’s telling you what not to blame.\n\nKnowing that a metric moved because of external circumstances prevents organizations from chasing the wrong explanations, setting unrealistic expectations, or concluding that a team suddenly became less effective when nothing about the team actually changed.\n\n### The durable part\n\nThere is a reason I keep coming back to these examples, and it is not just that they are fun to share at a dinner party.\n\nIt is tempting to think of developer-experience metrics as a way to evaluate developer tools. But that is too narrow. Good developer metrics measure outcomes, not interventions. They tell us whether developers can do focused, meaningful, high-quality work. The intervention itself might be a faster build, a better office, a meeting policy, or even something as unexpected as Daylight Saving Time.\n\nThat distinction is what makes these measurement systems durable.\n\nFive years ago, organizations were asking different questions than they are today. Five years from now, they’ll ask different questions again. AI is the dominant topic today, just as cloud development environments, CI/CD, or code review tooling were at other points in time. The interventions evolve. The outcomes we care about—Speed, Ease, Quality, and Thriving—do not.\n\nThat’s why I don’t think AI is a special case. It is simply the latest intervention whose impact we want to understand. The questions remain the same: Does it help developers do better work? Does it reduce friction? Does it improve quality? Does it help people thrive?\n\nThe tools will continue to change. The interventions will continue to change. The measurement doesn’t have to.\n\nIt also leaves an interesting question for another day: if these ideas apply so well to software engineering, how much further do they extend?\n\nThat’s it for this week. Thanks for reading.\n\n-Brian", "url": "https://wpnews.pro/news/the-unexpected-things-developer-metrics-can-measure", "canonical_source": "https://newsletter.getdx.com/p/the-unexpected-things-developer-metrics", "published_at": "2026-07-31 10:45:41+00:00", "updated_at": "2026-07-31 10:59:15.232724+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["DX", "Brian Houck", "Seattle"], "alternates": {"html": "https://wpnews.pro/news/the-unexpected-things-developer-metrics-can-measure", "markdown": "https://wpnews.pro/news/the-unexpected-things-developer-metrics-can-measure.md", "text": "https://wpnews.pro/news/the-unexpected-things-developer-metrics-can-measure.txt", "jsonld": "https://wpnews.pro/news/the-unexpected-things-developer-metrics-can-measure.jsonld"}}