Live data from Hacker News

Developer Experience: Fundamentally harder than normal UX

gabrielpickard.com

51–60 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#51
post #8

Earlier quoted context omitted.

I think even complex products should have a linear progression from newcomers, curiously exploring the product for the first time, to experts, who want to do certain tasks as fast as possible. It's simply not possible to learn vi by just using vi. Also, the author emphasizes that just dumbening a product is not the solution.

> It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that…

I certainly learned vi from vi (or I guess vim to be specific). The start page says "type :help or press ", which led me to the help pages (and maybe doing vimtutor, can't quite remember), and then I "learned vi(m)" just working at it, poking and prodding at the various corners (and the manual for is excellent). No Google, no stack overflow, no teacher. Later I started looking up other peoples configurations and stuff, as well as some advanced guides, but I was already basically proficient at that point.

On the other hand: I don't see what's so bad about a product for professionals where you might need a teacher to help you learn. Photoshop is not a simple product to use if you've never interacted with it before and most users go through some tutorial or has a teacher or something. It doesn't mean that Photoshop has bad UX. This goes for lots of software made for professional use: try learning Autodesk Maya or Avid without external resources, I dare you.

Re: Developer Experience: Fundamentally harder than normal UX

#52
The other day I was using MusicBrainz Picard and it occurred to me just how absolutely pleasant it is. It uses standard desktop widgets, is fast, has some nice attention to detail and consistently accurately relates the state of things, is powerful, and stays out of your way. It—and this is #1-with-a-bullet more important than every other UX concern—behaves consistently.

I don’t think it would survive a pass from most “UX” folks in such a nice state. It 1000% wouldn’t survive a designer or hybrid designer/UX person (it wouldn’t look pretty in screenshots on their portfolio).

The main problems in software tools are lack of consistent behavior, lies, and tons of ways to use a bunch of tools that all do basically the same thing (and you’ll probably have to know more than one). The hardest part’s not using them, exactly, it’s knowing all the different, stupid reasons they break. It’s a general quality issue more than a broader UX thing, I think. That extends to libraries. And I don’t also mean tools and libs from big names—I mostly mean them.

Re: Developer Experience: Fundamentally harder than normal UX

#53
post #4

> We've simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system This stuck out to me, there seems to be a trend in UX/UI where any move away from the "simplest path" is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that…

I think there should be a clear distinction between your tools and... let's call them "utilities" what comes to UI. It is perfectly okay to make electricity plug, water faucet, toaster and the power button on your computer not only so easy that an idiot can use them, but so easy that an idiot can't use them wrong. Not only because requiring mental energy to use these is irritating but also because it can be dangerous.

Your tools, then again, chainsaw, microscope, text editor... have no reason whatsoever to have an UI that is intuitive without training[1]. Because without training you are anyway going to be either dangerous, useless or in best case just really unproductive.

[1] of course, the UI needs to be efficient after training.

Re: Developer Experience: Fundamentally harder than normal UX

#54
post #15

This. Despite latest -cli trend, anything slightly more sophisticated requires to create a structure, then create structures in nodes, then a configuration structure, structures all the way down. One could object that everything we do is structures, but there is no ui to these, only a text file and a formal documentation (if you’re lucky). Text files and their disconnection from a documentation is a root of all our e…

Try this:

https://codesolvent.com/config-node/

Re: Developer Experience: Fundamentally harder than normal UX

#55
post #4

> We've simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system This stuck out to me, there seems to be a trend in UX/UI where any move away from the "simplest path" is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that…

I'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand thi…

Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer

Re: Developer Experience: Fundamentally harder than normal UX

#56

Earlier quoted context omitted.

I'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand thi…

Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer

There is a difference between being an engineer and holding a license (e.g., PE) from some organization.

Re: Developer Experience: Fundamentally harder than normal UX

#57
"DX" is indeed important. Myself and a number of other academics have been researching the topic for years.

See here for examples of publications in the area: http://web.eecs.utk.edu/~azh/publications.html

Also relevant, I wrote a blog post for students to get started in human factors in software engineering: http://web.eecs.utk.edu/~azh/blog/guidehciseresearch.html

Re: Developer Experience: Fundamentally harder than normal UX

#58

I don't think that DX is harder than UX because developers somehow have a more complex task than everybody else, and that there's therefore a richer "experience" to navigate than in other domains. I think it's because developers tend to be developers, so are more aware of and willing to accept the nuances and complexities that go into development. In other words, we've got a more detailed understanding of the develop…

A healthy exercise, I think, is to replace "developer" with "scribe" whenever we have these conversations. It becomes clear that in large part it is the overall culture that is missing the point -- which should be a kind of mass literacy. Smalltalk is a different universe indeed, but its goals were also completely different from today's. Its creators assumed that "using" a personal computer would be, in part, "programming" it, and they sought to define what that interaction would be like.

Re: Developer Experience: Fundamentally harder than normal UX

#59

Earlier quoted context omitted.

Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer

There is a difference between being an engineer and holding a license (e.g., PE) from some organization.

So just anybody can call themselves engineer?, don't you realize this is a disservice to the actual engineers?

Re: Developer Experience: Fundamentally harder than normal UX

#60

Earlier quoted context omitted.

I'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand thi…

Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer

Does your state recognise software engineering as a chartered profession?
Post reply on HN