Pragmatic Developer Experience

If you find the developer experience content helpful, supporting via Ko-Fi helps sustain the research, experimentation, and writing. ko-fi.com/pragmaticdx Thanks for being part of this. 🙏

Developer friction is rising while leaders double down on AI and metrics. The only way to fix what’s actually broken is to ask the people doing the work.

Success isn’t about pushing developers harder, it’s about shaping the system around them. When doing the right thing feels effortless, excellence becomes inevitable.

Why developers are slower with AI tools despite believing they're faster and what actually works

The three-layer system, exact scripts, and implementation playbook for protecting your focus when everyone's convinced their request is the exception.

Max Kanat-Alexander breaks down why cycle time, focus, and cognitive load determine whether your engineering team thrives or burns out

Every team thinks one more feature will make the launch better. In reality, it’s the fastest way to delay, over-engineer, and burn out before you ever ship.

Quick sale on annual subscriptions – 50% off. You'll get a full year of weekly posts about the messy reality of developer experience: the organizational dysfunction, the culture issues, the stuff that actually matters beyond just tooling. blog.pragmaticdx.com/e884d54f Lock it in while you can!

Every team thinks one more feature will make the launch better. In reality, it’s the fastest way to delay, over-engineer, and burn out before you ever ship.

Success isn’t about pushing developers harder, it’s about shaping the system around them. When doing the right thing feels effortless, excellence becomes inevitable.

Why developers are slower with AI tools despite believing they're faster and what actually works

The three-layer system, exact scripts, and implementation playbook for protecting your focus when everyone's convinced their request is the exception.

Max Kanat-Alexander breaks down why cycle time, focus, and cognitive load determine whether your engineering team thrives or burns out

Success isn’t about pushing developers harder, it’s about shaping the system around them. When doing the right thing feels effortless, excellence becomes inevitable.

Every team thinks one more feature will make the launch better. In reality, it’s the fastest way to delay, over-engineer, and burn out before you ever ship.

Max Kanat-Alexander breaks down why cycle time, focus, and cognitive load determine whether your engineering team thrives or burns out

The three-layer system, exact scripts, and implementation playbook for protecting your focus when everyone's convinced their request is the exception.

What's the most ridiculous workaround you've built because fixing the actual problem would require approvals from 6 different teams?

What's your team's unspoken rule for when documentation is 'good enough' vs when it needs to be perfect? Or does everything just stay in draft mode forever?

What's the programming language you love that nobody else seems to care about anymore?

How do you explain to non-technical stakeholders that 'just add a button' is actually a 2-week project touching 8 different services?

Your junior developer asks why we don't just rewrite everything in [hot new framework]. What's your response that doesn't crush their enthusiasm but also acknowledges reality?

When you discover a critical security vulnerability in production, what's your incident response? Fix first, tell people later, or panic immediately?

How many layers of abstraction does your codebase have? At what point does 'clean architecture' become 'I need a map to find where anything actually happens'?

Your PR has been approved but you spot a bug right before merging. Do you fix it in a new commit, start over, or just merge and fix it later?

When documentation says 'deprecated' but provides no alternative or migration path, is that helpful or just mean?

What's your strategy when you're 90% done with a feature and realize your entire approach was wrong? Start over or hack it together and refactor later (aka never)?

How do you keep learning new technologies when you barely have time to master what you're already using?

You inherit a 5000-line function that nobody understands but somehow runs the entire business. Do you refactor it or treat it like an archaeological artifact that must never be disturbed?

When you finally solve a problem that's been haunting you for days, do you feel accomplished or just annoyed it took that long?

When your test suite takes 2 hours to run, do you actually wait for it or just push and pray? What's your acceptable CI/CD wait time before you start cutting corners?

Your tech lead wants to adopt a new technology because it's interesting, not because it solves a problem. How do you push back without seeming negative?

What's your team's policy on Friday deployments? Forbidden, encouraged, or 'deploy and flee'?

What's your ratio of time spent coding new features vs maintaining/debugging existing features? Is it what you expected when you became a developer?

Your error message says 'Something went wrong.' Thanks. Super helpful. What's the most useless error message you've encountered that made debugging 10x harder?

What's your record for longest period of uninterrupted coding time? Mine is pathetically low. Are we all just glorified context-switchers now?

What's the most 'enterprise' thing about your codebase? XML configuration files? Factory factory factories?

What's your team's policy on technical debt? Pay it down regularly, ignore it until it explodes, or just keep adding to the pile?

How do you balance writing clever, elegant code vs code that's so simple your future self won't need to decipher it?

What's your take on 'code ownership'? Does it create accountability or just bottlenecks and knowledge silos?

When you find a genius solution on Stack Overflow, do you understand it before using it or just copy-paste and move on?

What's worse: A codebase with zero tests or a codebase with tests that never fail even when everything is broken?

Success isn’t about pushing developers harder, it’s about shaping the system around them. When doing the right thing feels effortless, excellence becomes inevitable.

Every team thinks one more feature will make the launch better. In reality, it’s the fastest way to delay, over-engineer, and burn out before you ever ship.

Max Kanat-Alexander breaks down why cycle time, focus, and cognitive load determine whether your engineering team thrives or burns out

What's the passive-aggressive way people on your team signal they disagree with a technical decision without actually saying it? Slow code reviews? 'Interesting approach' comments?

Your production bug affects 5 users. Your ticket backlog has 200 items. How do you decide what actually matters vs what just feels urgent?

Your team has 3 different Slack channels for the same project, 2 Notion pages, and some Google Docs nobody can find. Is this organization or just distributed chaos?

Your local environment works. Staging is broken. Production is fine. Nobody knows why. How long do you debug the mystery before you just accept that staging is cursed?

How do you tell a senior developer their code is a mess without starting a war? What's the diplomatic phrase that actually works in your experience?

What's the feature request you keep pushing back on because you know it'll break everything even though it sounds simple?