Developer Experience: Fundamentally harder than normal UX

Developer Experience: Fundamentally harder than normal UX
gabrielpickard.com

This is why there are occasional spasms of "back to basics" or plaintive remembering of the BBC Micro. You power it on, it beeps, and within a second you're in the interactive development environment. Typing code runs it directly. Typing code with a line number adds it to the program. No configuration, containers, downloads, updates, dependencies or uninformed choices to make.

> Why do we treat this as a moral failing instead of a usability issue?

Yes. This applies in so many places. Learn from "Poka-yoke". The system should make it easier to do safe things and harder to do unsafe things.

> Tests are a usability dead end

Depends what you mean by "tests". A strong type system does away with certain categories of test (and conversely a lot of the heavy unit testing usage comes from communities with weakly typechecked languages). But both types and tests are capturing a human-level requirement of "if X then Y", a constraining of the problem space.

This is why many successful code archaeology maintenance projects start by building a test suite to capture the current functionality of the program. An executable requirements document.

I really like to explore new DX approaches (just recently, I published an extension for VS Code enabling visual debugging [1]). But I find it hard to make a living out of it, as so many companies find it granted that everything is free. They would rather hire another developer than paying for licenses that might effectively increase the effiencency of the developers they already have.

[1] https://github.com/hediet/vscode-debug-visualizer/blob/maste...

We accept the heritage of developer tools - the keyboard-driven interface that displays to a teletype emulator, the edit-compile-debug workflow - and build tools that improve the processes that have built around those legacies. This is why when something comes out of left field like Adele Goldberg and colleagues describing Smalltalk, we find it easy to adopt the approach to code organisation on offer and hard to adopt the image model, browser-based workflow, debugger-driven iteration, and other changes.

Meanwhile, when we go out into other domains, we use a little bit of understanding of that domain, a lot of reasoning by analogy, and an intention to "disrupt" what already exists and "eat the world", and create something that works very well for the spherical user in a vacuum without all of the detailed understanding that comes from having grown up in the system and learnt from people who grew up in it even longer ago.

And I feel this is a very similar situation with other tools. I edit code with vim, in a terminal. This is simple as dirt. I do it because it is simple as dirt. Visual Studio is incredibly complicated to me because to do the creating code part my job I need to understand the following:

- How code is built.

- How to build the code without using any graphical front end.

- But now when you bring VS into the mix I need to also understand visual studio. It does not remove complexity, it adds it.

Similar thing with debugging, I need to understand all the ins and outs of debugging but now bring VS into the mix and I need to understand it's stupid UI.

I like simple, my mind is simple. I can learn things, if there are rules and patterns it makes it easier to learn, but the less things I have to learn the happier I am. I don't have an option to not learn some things, like how to do build automation, how to debug code, how computers work, etc. But I do have an option to not learn something entirely useless like VS.

I think the lie being sold is that somehow you can be a programmer without actually knowing how to use a computer. And to know how to use a computer is not the same thing as knowing how to click on things in the UI with a mouse. To know how to use a computer you need to understand how to use it to do automation - and once you need to do this VS is just a nuisance.

Just a rant I guess.