Developer Experience: Fundamentally harder than normal UX

Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every time you move away from the default behavior.

I think you are missing an important aspect: VS can help you in mental tasks the same way a jackhammer can help more than a pickaxe in physical tasks.

Sure, the pickaxe is simpler, but it will take you a lot longer to break that concrete with a pickaxe than with a jackhammer, because of simple human limitations.

Similarly, refactoring and advanced code navigation support takes a while to learn how to use, but once you do, it empowers you through technology to quickly do things that your mind would take much longer to do by hand.

For example, say you want to extract some code from the middle of a function into a separate function. With vim, you would generally have to manually move the code, write the new function header, then start to painstakingly inspect the code to identify the parameters to pass between the two. You will probably make mistakes and have to wait for the compiler to find them. All in all, assuming it's a bit of hairy code, it might easily take you more than an hour to get it working. In VS, you would type ctrl-r, ctrl-m (Refractor, extract Method) and it would automatically detect all of these for you, pop out a dialog box, you'd enter the new function name, Tab, param name, tab, param name etc, and enter when you're done. Maybe 5 minutes all in all, assuming you also do some ctrl-r, ctrl-p (refractor, parameter) afterwards to extract some larger expressions back into the original function.

Similarly, you have things like 'analyze data flow to...' which can find all places in your program where a particular value can be written to, and do that recursively until you get to the original source. Same thing - this can be done by hand with a series of finds and so on, but an advanced tool will just help you do it faster.

But, just like with advanced editing in vim, you need to take the time to learn the tool until you can get the most out of it. Same as the first time you enter vim you're likely to fumble to even be able to exit, you can't expect to be productive in VS if you don't take the time to learn what it can do for you.

I disagree with the premise.

The problems the author identifies largely have already been solved. The solutions just haven't become universal, generally for reasons completely unrelated to the actual problem, and more to do with PR.

For things like vi, I'm developing the "left handed mouse" analogy:

Many mice are ambidextrous (e.g. the Apple puck). Most are weakly right-handed with a slightly assymetrical shape. Some are very strongly right-handed (e.g. vertical mice) and can't be used sensibly in the left hand. So left-handed mice also exist.

Some people are naturally left-handed. We (as a civilisation) used to treat this as aberrant but have now recognised it, and that different tools suit different people.

I believe that something similar exists in programming tooling in relation to how people think about programs. There are clearly some people who have a strong, unusual "handedness" and have developed tools to match (e.g. Colorforth). A few people discover these and find them amazingly usable. Most other people find them baffling.

Consider the three propositions:

a) Jimi Hendrix played guitar in the wrong way with the strings in the wrong positions

b) Jimi's configuration was correct and everyone else was wrong, because he's producing the objectively best music

c) Jimi was left handed, and had constructed an accomodation which worked for him but should not be expected to work for anyone else

Far too many discussions of programming tools devolve into (a) versus (b), largely because people want there to be an objective ranking of who the best programmer is and what the best tools are, rather than allowing for diversity of (programmer x tool).

I also use it, but it is quite buggy and not quite enough. Luckily xfce is now available for RHEL8 via EPEL.