As AI-augmented development becomes standard practice, engineering leaders face mounting pressure to demonstrate its impact. Yet most organizations are measuring AI adoption and output while the effect on developer experience (DevEx) remains largely unknown. The right metrics can close that gap, surfacing the everyday friction developers face and monitoring the real impact of initiatives such as AI rollouts. But with more than 120 metrics in circulation across frameworks, companies, and scientific literature, identifying the right, meaningful, actionable ones for a specific context has become a challenge in itself. This article introduces DevEx Metrics Compass , a public, open-source web app built on a structured analysis of that landscape across more than 50 engineering organizations. Alongside the tool, we share what the dataset reveals about how DevEx is measured today and where the gaps lie. Whether you are new to DevEx measurement and looking for a first meaningful set of metrics, or a seasoned practitioner assessing whether an existing collection has the right breadth and depth, Compass helps teams navigate the fragmented landscape and identify measures that actually matter for their context and goals.
Please make my predictions come out wrong. The only bit left of FOSS as we know it will be that users will be able to read the source code. As reproducible builds catch on, they might even be able to compile that, as long as they make no modifications.
There are fewer things more maddening than watching someone wander around a space bumping into ideas as if they're in a pinball machine, learning nothing more than a few words that might be used at a cocktail party to impress the guests.
You can ignore it, tie it to unrelated company initiatives, or feign ignorance and simply not offer solutions that add to it. Or… you can adopt more above-board techniques such as Crawl/Walk/Run and the Reverse Farmer’s Rule, which reframe projects so that confronting tech debt is an upfront part of the plan.
The cost and tooling of formal verification have reached the point of widespread use. By eliminating the cost of writing proofs, AI is removing the biggest barrier to formal verification. This makes it easier than ever to build software with critical business rules that are guaranteed to be mathematically correct, rather than merely tested.
While frameworks such as SPACE and DORA establish that developer productivity is multidimensional, many organizations continue to struggle with translating those principles into operational systems that drive improvement. This article introduces Engineering Thrive (EngThrive), a system deployed at Microsoft that organizes productivity into three dimensions: speed, ease, and quality, with “thriving” as a well-being guardrail. EngThrive pairs outcome-oriented North Star metrics with diagnostic submetrics, combining system telemetry with developer surveys for scale and context. The article outlines the design principles, data platform, and dashboard ecosystem required to operationalize this approach. Case studies demonstrate how outcome-oriented measurement enables sustained, system-level improvements. Finally, the article shows that EngThrive functions as a general-purpose evaluation language applicable to tools, AI, and organizational policies. EngThrive is offered as a concrete model for organizations seeking to move beyond measuring activity toward improving outcomes.
The xz attack seems to be the first major attack on the open source software supply chain. The event-stream attack was similar but not major, and Heartbleed and Log4j were vulnerabilities, not attacks. But the xz attack was discovered essentially by accident because it made sshd just a bit too slow at startup. Attacks, by their nature, try to remain hidden. What are the chances we would accidentally discover the very first major attack on the open source software supply chain in just a few weeks? Perhaps we were extremely lucky, or perhaps we have missed others.
We build apparatus in order to show some effect we're trying to discover or measure. A good example is Faraday's motor experiment, which showed the interaction between electricity and magnetism. The apparatus has several components, but the main feature is that it makes visible an invisible force: electromagnetism. Faraday clearly had a hypothesis about the interaction between electricity and magnetism, and all science starts from a hypothesis. The next step was to show, through experiment, an effect that proved or disproved the hypothesis. This is how empiricists operate. They have a hunch, build an apparatus, run an experiment, refine the hunch, and then wash, rinse, and repeat.
Mismatches between the interfaces promised to programmers by source languages and the capabilities of the underlying web platform are a constant trap in compiling to Wasm. Even simple examples such as a C program using the language's native file-system API present difficulties. Often such gaps can be papered over by the compilation toolchain somewhat automatically, without the developer needing to know all of the details so long as their code runs correctly end to end. This state of affairs is strained to its limits when compiling programs for the web that use multicore concurrency features. This article aims to describe how concurrent programs are compiled to Wasm today given the unique limitations that the Web operates under with respect to multi-core concurrency support and also to highlight some of the current discussions of standards that are taking place around further expanding Wasm's concurrency capabilities.
Even something as innocent as addressing comes from a rich design space filled with tradeoffs between important considerations such as scaling, transparency, overhead, and programmer control. These tradeoffs are just some of the examples of the many challenges facing programmers today, especially as we drive our applications to larger scales. The way we refer to and address data matters, with reasons ranging from speed to complexity to consistency, and can have unexpected effects down the line if we do not carefully consider how we talk about and refer to data at large.
