The purpose of this article is to provide a straightforward way for engineering teams to quantify their impact, and to help developer experience teams build stakeholder trust through transparent and predictable prioritization.

Estimating engineering efficiency savings can help direct actions.

Developer Productivity’s definition matters. Two problems stand out to me when defining it, (among many): As a metric it is relatively ineffective for improving stakeholder and business outcomes. As a term its ambiguity causes more problems than it solves for anyone defining it, learning about it, or generally discussing engineering optimization.

User Experience (UX) has separate definitions for “a user experience” and “the field of User Experience”. Developer Experience (DX, DevEx) does not. The result is ambiguity between “a developer experience”, experience optimization, and engineering outcomes. This post disambiguates them by defining and contextualizing a developer experience, the field of Developer Experience (DX, DevEx), and DX’s relation to engineering outcomes.

Startup SaaS Company. Two years in. Funds running low. Our JavaScript is a ball of mud. One page costs $94k per year to maintain. 140 pages. How did we get here?

“What story do I want to tell?”