aevv.net

2026-06-25 draft

developer experience

i've cared a lot about developer experience for most of my career. i've made the majority of my career decisions around whether it's enjoyable to work on that thing, or solve that problem, or whether i can affect the right changes. that's partly because no one should spend their life being bored, but also because anywhere that resists making work fun is ignoring an easy opportunity to get more done

in my experience, enjoying the work (the tech, the process, the people, the org, the product, whatever) has me being far more productive; caring more about the problem, putting more mental energy into the solution, higher personal accountability. it lets me set the bar high, show other people where that bar is, then both empower them to reach it while holding them accountable for that growth. if it's not fun, it's difficult to give a shit about improving the world around us

disclaimer: i work primarily in startups (50-300 person) and talk to other leaders of similar shapes, i can't vouch for how my experience would apply in "big tech". there's a spectrum of experiences where none, some, or all of this is relatable and/or applicable

my advice to engineers: fun should be your goal

a quick detour on fun

fun is subjective. fun at work has to align with being impactful in that context - i'd rather ride a motorbike or sit in the sun with a drink than be at work, but while at work i want it to be as enjoyable and fulfilling as possible, for myself and my colleagues. fun for me is being able to solve problems, learn new things, and see the value of the work i've done. fun is also building toy projects or solving a problem because the process itself is enjoyable. aligning fun with usefulness has given me the biggest gains in life, and learning what levers to pull or hills to die on lets us have fun while growing our impact.

the real case for fun

given the huge value (and cost) of tech workers, a lot of research goes into effective and accurate measuring of developer productivity. this has evolved dramatically over the past decade, and most people i talk to are unaware of modern learnings

before DORA, a mix of output metrics, activity tracking, quality measures, and maturity models were used that were widely considered flawed. or worse, "management" would demand metrics and engineers would dispute their efficacy, often gaming them (toward negative outcomes)

DORA came along and showed that some objective, measurable activities have statistical correlation with business success, and in Accelerate published the four key metrics:

these weren't new, but they now had explicit backing from lots of research as to how they correlate with meaningful business metrics (namely profitability, market share, # customers). being good at these things doesn't make you successful, but it enables success. a product or business can still fail, but it's unlikely the engineering capability is the reason

doing well on DORA is fun. you can merge lots of code, it's live quickly, you have less incidents, and when there is a problem it's easy to resolve. sounds great!

and many companies adopted DORA metrics. but in 2026 i still talk to engineering leaders who have never heard of Accelerate (which blows my mind). but those four metrics were not the end of understanding engineering org effectiveness

away from metrics, toward experience

next we got SPACE which literally leads with Satisfaction:

Satisfaction is how fulfilled developers feel with their work, team, tools, or culture; well-being is how healthy and happy they are, and how their work impacts it.

imo SPACE was a bit too vague and hard to implement compared to DORA. loads of dimensions, lots of decisions to make. but the good news is it wasn't long after SPACE that we got DevEx and DXI. it gets a bit sales-y from here, but stay with me

DevEx makes a solid attempt to simplify SPACE, focusing more on developer experience (duh). where it does it right is it's a paper, framework, and a product.

disclaimer: i (through Codat where i work) am a client of DX, receive no benefit for talking about them, but personally highly recommend their platform, and i'll explain why

SPACE is nebulous/ambiguous and requires a lot of figuring out what to do. DevEx is something you can buy. they have loads of peer reviewed papers and plenty of public research and work with the leading researchers when it comes to understanding developer productivity (such as Dr. Nicole Forsgren, who co-founded DORA and co-wrote Accelerate)

DevEx boils down to DXI (Dev Ex Index) - it's four metrics again:

you can boil it down further and look at ONLY effectiveness - a single number based entirely around a subjective, engineer-answered survey - which gives one number to "estimate" how good the developer experience at your org is:

Each one-point gain in DXI score translates to saving 13 minutes per week per developer, equivalent to 10 hours annually.

this quickly adds up with more engineers to become a possible huge productivity gain. the survey is the part that's really cool to me: DXI is 100% subjective, from survey responses. if engineers FEEL productive, they probably are. you should measure objectively AND subjectively, but if the engineers feel different from your measures, you should trust the engineers over the data

productivity is a great "pat on the back" for managers but why do i, an engineer, care? because those 13 minutes wasted are not fun. it's flakey build/test, it's fighting to get your code reviewed, it's pointless meetings, it's missing requirements and acceptance criteria, it's insert annoying friction point here. orgs who do well on DORA/SPACE/DevEx are generally more effective, and their engineers are happier because the friction is gone.

you can of course implement DevEx/DXI without paying for a product. but even DORA was difficult because implementing it is half the battle, and lots of tools exist (with google supporting a now-archived implementation)

i don't trust your sales pitch, there's incentives for them to make it look good

EngThrive from Microsoft (30k-60k engineers, regardless of any bias they give a shit about the ROI of those people). the tag line explains it well:

Make It Fast and Easy to Do Great Work

at MS Build in June 2026, Tim Bozarth talked through this framework. differentiating activities from outcomes, but caring about activities that lead to good outcomes was where they see the wins. particularly compared to pre-DORA days, you can create outcomes that actually benefit from engineers gaming the activities - and it turns out that 1. those activities are the same things that good engineers give a shit about doing and 2. even if it's gamed and feels redundant, it has the same benefit

the concrete example on time to first PR, big quote alert:

Now this is fun. I was asked this question a number of times: "but wait, isn't this metric so easy to game? What does a first PR tell you? Couldn't they just put in a no-op comment commit on some repo?" The answer is absolutely, and it does not matter, because the results were amazing. It doesn't matter if the first commit is a no-op. What it means when you're able to put a no-op commit through to production is that your machine works. You're attached to the infrastructure. You understand the deployment cycle. You understand how your code is present. You understand what you needed to do to get code reviews to go through that whole cycle. You're already exposed to it. So while it seems easy to game, when you game an outcome metric, you create the success that you sought to create.

i think the research findings are fun, but the conclusion is fun for everyone: you want us to get stuck in ASAP and figure out how to get code changes live? hell yeah!

is this all just correlation?

it's not possible to say there's direct causation because fun and productivity aren't the only two things in existence. but i think it's logical to say there's a compounding flywheel here: remove friction -> be more productive -> enjoy work more -> remove more friction...

it gets to a point where there's far less annoyance to remove, and far more of our time can be spent on the things that are truly valuable

ok enough of the research story, this is manager bs not fun

most good engineers i've worked with care about their work being used. they care about getting shit done, being efficient with their team and their brains. they want the space to do deep work when needed, without context switching to deal with shitty problems. the ones who want to go away for 3 months on their own and come back with a big rewrite or new system often fall into the brilliant jerk category

ultimately, most of us are employed at a company, paid a salary, to perform a job that aligns to what that company is trying to achieve. and we spend a lot of our time doing this. i like to think we want to do this as effectively as possible for our own satisfaction and growth, and we have a way to show that making our lives as easy as possible can enable all those business objectives

all the research is pointing to reducing friction, making it easy to do work (either small, fast changes - or bigger, focused problem solving). it's great to work somewhere this is prioritised and you're told to do this. but the reality is often bottom-up change will have the quickest impact. and making those changes - improving CI, code being easier to reason about, tests that don't flake, less (pointless) meetings, less incidents, faster local builds, lower PR cycle time, etc. etc. etc. contributes to every other business goal

is that fun?

to me it is, to other engineers i respect it is. finding ways to align job satisfaction with business impact is a surefire way to grow professionally. and getting higher recognition, satisfaction, autonomy, and reward lets you do more of the things you enjoy - creating a compounding loop of improvement and enjoyment. as it gets easier to make changes, you can make more changes. you can make changes that improve your products easier, faster, with higher quality, more consistently. you have less cognitive overload. you can see and communicate how easy it is. you can work with your colleagues on the things that matter, instead of being annoyed at the state of things. thats fun

but how?

all of the above has been enough fuel for me to get buy in. i see engineers fail here when they can't explain why its worth doing something, or they want to do things that are fun for them but not beneficial to their team or business. it's easier than ever to understand what to improve and how that will benefit you, your team, and your org

concrete examples

some things i've fixed in the past because they were stopping me from having fun, not because i cared about some metric changing:

most of this is standard "good engineering" in my opinion, but i know many people will empathize with problems like this and will be unsure of how to action improvements. saying "this is a problem" to non-technical folk doesn't share the impact of a fix, but we know there's high impact

AI and developer experience

agentic engineering fundamentally changes the cost of improving the developer experience. Will Larson specifically calls out migrations:

Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time. As the initial cost of migrations goes down, the reward/penalty of each migration’s quality goes up: even small sharp edges will break your colleagues’ mental models about the software you co-maintain. The impact of individual judgment on your company has never been higher.

i'd class most devex improvements as a "migration" - you're trying to do the same thing but easier, faster, more consistently. and the things in the past that took a lot of articulation and effort to do, can now be done with trivial effort as a side quest. what was 2 weeks of work 5 years ago is now a couple of lunch breaks of an agent in the background

as our industry gets more into agentic engineering, many engineers are finding themselves able to solve problems they previously couldn't get the time for. these developer experience problems are critical in an agentic workflow - the success of an agent depends massively on how quickly and easily it understands what to do, can make a change, then verify that change, and ultimately get it live successfully (with or without an engineer being involved).

fun comes in when deciding what to solve. knowing all the above research, owning migrations to make your life easier and more enjoyable can start the compounding, and quickly accelerates into getting more done, easier.

my belief with teams struggling to get value from AI is that they don't have a good developer experience story. if it's hard to know what to do, write the code, test it, release it, operate it - throwing agents into that culture makes code output increase with no supporting structure. the recent rise of LOC and token usage celebration shows that people are caring about the wrong things.

takeaways

autonomy is taken, not given

every engineer will have a story about "product" or "delivery" or "the business" stopping them from solving that one big problem that'll fix everything. few engineers will find ways to solve it regardless. bet on yourself, just go fix the fucking problem

with the right data, influence, and communication: no problem is unsolvable

to make the right bets, understanding what's important, why, and how to articulate it is an invaluable skill. if you currently can't articulate the friction, the frustration, the things that make work boring or annoying - a great first step is shining a light on it

all of this is even more important in an agentic world

agents don't require anything different from what we already know works for us - good developer experience lets us have fun, which makes us productive. agents (probably) don't care about fun, but we do care that they're productive

← all posts