Why DX doesn't matter

Developer experience, or shortly DX, seems to be the number one thing that people pay attention to in their chosen tools/frameworks.

Jump on any online discussion, and you will hear “DX that framework”, “DX this tool”, etc. DX, together with “fast prototyping”, “rapid development”, “developer ergonomics”, seems to be the only thing everyone cares about nowadays. I’m here to argue that neither DX nor any fast/rapid development/ergonomics enhancement tools/frameworks—truly matter.

The entire premise of DX enhancement frameworks/tools is that the biggest and most damaging aspect of writing software in a productive manner—is indeed the writing itself. However, I bet that if we observe a lot of developers and measure the time they spend between writing code, i.e. producing new lines of code, compared to reading code, i.e. understanding and navigating previously written code, reading documentations, reviewing code written by their peers, etc—we will see numbers in the vicinity of 20% being the writing part to 80% being the reading part.

Keep in mind that these numbers are for coding activities only, I omit any time spent on corporate rituals like meetings and technical discussions, producing technical documentation, chatting with co-workers, and general procrastination. From my experience, an engineer is lucky to spend 2 full hours out of an 8-hour day in coding related activities, the rest of the time is spent on other tasks. And out of these 2 hours, the majority of the time is spent on reading/understanding code, rather than producing code. This alone should be a strong indicator that DX doesn’t really matter, because if you want to optimize for productivity, you better optimize for ease of reading and understanding code (or abolishing meaningless corporate rituals, but the end of the world will arrive sooner than management will free us of meetings).

I believe that this was the purpose of Go. It’s an ugly, in my opinion, and very verbose language, but it’s super easy to read. But let’s say you still disagree with me. I shall demonstrate it by looking at one of the tools I like: Svelte/SvelteKit.

Svelte and Kit are the king of DX. Jump on HackerNews or any web development related subreddits, and you will see how people praise Svelte and Kit. It is a great framework indeed, a very refreshing approach to web development. But, as many other frameworks, it optimizes for the wrong things. While it has a great DX, it breaks quickly when you are done developing and now need to move to production. You will, eventually, encounter weird bugs with hydration errors, or that window is suddenly undefined. Moreover, while you develop with a hot reloading server behind npm run dev, after you deploy your npm run build code, parts of your code won’t run, even though in development, your DX was great. With time, you will realize that there is a prerender = true in some obscure +layout.ts file somewhere in your hierarchy, and while npm run dev behaves in one way, thus allowing you to have great DX, the production version behaves in a completely different way.

You could say that I’m a terrible software developer, a noob with Svelte, and any experienced developer should have known these things. And by claiming that you will support my point. DX is great when you begin, even as a newbie. This is what allows you to move fast. But when time comes to actually run and maintain your code, you will spend a lot of time trying to understand why this particular piece of code does not execute. And it’s only after you’ve burned yourself, and now hold this important lesson, and contextual knowledge, in your head—you will be able to move at a decent speed post initial development.

I had similar experience with NextJS, where everything would work great during development, but in production I’d get hydration errors. And I bet people have similar experience with Laravel, Django, or Ruby on Rails—all of them claiming to have tremendous DX. But the moment you need to actually run your code, maintain it, and fix bugs in production, all your DX is thrown away with lack of strong typing, magic shenanigans, and the need to hold contextual knowledge related to the current minor version of your framework.

On the other side, however, we have poor DX in the form of Rust. Jump on the same forums I mentioned early, and you will see all kinds of accusations thrown at Rust: the borrow checker fucks you up, the language is hard to pick up, the DX is poor, etc. But once you finish your application, not without pain and tears, it will run pretty much forever. Yes, there could be logical bugs like in any software, but there won’t be surprises or weird behaviors. What you saw during development, will happen in production.

Moreover, when you come back to develop yet another feature, or fix yet another bug, there won’t be any surprises or hidden rocks. Refactoring will be a breeze; reading and navigating the code will make sense; and a chance for you to break something in an unrelated part of the application—is slim. All this without the need to hold enormous contextual knowledge, and without the fear that the next minor upgrade of your dependency—will spiral your productivity down the abyss.

Developers are obsessed with tools and frameworks that help them to be more productive. For years, if not decades, productivity meant speed of writing code, which is important, but it’s a very small part of the entire process of development in general, and if you want to optimize productivity, you better focus on other areas in order to gain more benefits.