What Makes a Great Developer Experience? (Category Productivity)

Interesting. report Max Kanat-Alexander with DPE Summit 2025 (More about the summit here). Max talks about three whales of good developer experience 1. Cycle time How long does it take from the idea to the result? 2. Focus How much time the developer has to work without twitching 3. Cognitive load How much extra you need to keep in mind to do a useful task

The idea is that almost any engineering productivity problem can be broken down into these three axes, according to Max. And he knows a lot about DevEx because he's been doing it all his engineering career.

• As the chief architect of Bugzilla Working on Code Health at Google Responsible for Developer Experience on LinkedIn Executive Distinguished Engineer at Capital One (Bank whose business model was inspired by the creation of Tinkoff) So to me, Max’s view of productivity doesn’t seem to be an abstract theory, but a practical experience.

The main point of the report is that a great developer experience is not about a beautiful interface of an internal development portal. This is about the systematic removal of barriers that slow down the engineer, knock him out of focus and make you spend your brain not on the product, but on infrastructure noise. Max essentially says that if the improvement doesn’t shorten the cycle, protect focus, and reduce cognitive load, then its value to DevEx is questionable.

Now for insights.

1Speed is not the mantra of “work faster.” From Only stress appears, and for real acceleration it is necessary to accelerate internal development cycles. (intercycle)For example, you can do

• Quick review.
• Less and clearer PR.
• Short build.
• Transparent CI/CD
• Faster local feedback. Real speed comes not from heroism, but from a well-tuned system.

2Focus is an undervalued asset Every interruption is expensive. An incomprehensible mistake, a sudden status rally, a tooling curve, noisy allerts - all this tears up the context. Reconstruction of context often takes much longer than the interruption itself. Developer productivity is often drowning not in big problems, but in constant small fragmentation of attention.

3Cognitive load - the main hidden tax If an engineer needs to remember the features of five piplins, three monitoring systems and seven delivery methods for a typical product task, then the problem is not with the engineer. Bad DevEx often looks like this: a developer came to do business stuff, and instead explores an internal zoo of platform solutions.

Very practical advice for technical managers can be obtained from the report. 1) Optimize not slogans, but the way of work Look not at abstract “performance”, but at specific bottlenecks: assembly, review, tests, deploy, waiting for access, diagnosing falls. 2) Remove the guessing phase If a CI/CD drops with a "something went wrong" message, you create an anti-DevEx. A good system doesn’t just report a failure, it helps you immediately understand the cause and the next step. 3) Treat Engineering Focus as a Limited Resource Linear engineers should not be without the need to drag on status syncs. Context Switching is one of the most expensive types of loss in development. 4) Reduce the Variability of the Basic Platform One standard CI, one understandable observability stack, a single way to run typical scenarios is not a “limitation of freedom,” but a way to bring teams back to the product. 5) Don’t confuse the platform’s internal portal with the solution. Glue together 20 Bad processes in one beautiful UI does not mean improving DevEx. Sometimes the best interface is no manual step at all.

P.S. Max has a lot of interesting talks, like "Developer Experience in the Age of AI Coding Agents." told

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign