Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer Experience: Fundamentally harder than normal UX

gabrielpickard.com

Post reply on HN
Print view View original

11–20 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#11

Post by ailideex »

Gehinnn wrote: post #8
kurnikas wrote: 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 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 long I think.

Re: Developer Experience: Fundamentally harder than normal UX

#12

Post by ChrisMarshallNY »

quelltext wrote: post #2

> Tests are a usability dead end -- I know this may be contentious, but I believe test suites are another realm of excessive moralizing en lieu of better tools and better processes. Too often they function as a security blanket that simply encases the parts of the code that are unit testable, while leaving the vulnerable, untestable bits fluttering in the wind. Approaches such as generative testing seem more promisin…

> So far I haven't found a good reason not to write tests...I don't quite see how tooling will get rid of the need for tests.

I write device control software. It’s very difficult to have true automated testing of things like drivers. You can write unit tests for subsystems, like packet parsers, but integration testing generally requires good ol’ “monkey testing.”

“Just write a mock!” Is what I hear all the time.

Mocking a device is a massive project; potentially larger than designing the device, itself. Remember that the mock needs to be of unimpeachable quality, and also needs to do things like simulate adverse signal environments.

DX for that kind of thing can be awful.

As far as basic DX goes...

Most developer tools are wrappers for command-line OS tools, and it shows.

They can also be quite buggy, and we accept this bugginess. I use Xcode, which is quite “crashy.” I am constantly fixing issues by deleting the build folder.

Back to testing...

I prefer test harnesses over unit tests. I write about that here: https://medium.com/chrismarshallny/testing-harness-vs-unit-4...

Re: Developer Experience: Fundamentally harder than normal UX

#13

Post by izietto »

kurnikas wrote: 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…

My point of view is different: there has to be a really strong reason to move my eyes from the code, and in the editors there should be respect for that. For example, I don't want to move from Atom to VSCode because VSCode has those huge icons that take space and distract me, when all I want in the default editor UI is the project directory tree and the code. Everything else should be opt-in.

Re: Developer Experience: Fundamentally harder than normal UX

#14

Post by z3t4 »

The problem with developer tools is not technical, it's all about the selling part. If you make a new superior developer experience, you think developers will instantly see the benefits? haha! You first have to teach them, then after a few month if you are lucky you will get a "aha, now I understand". So first you need to manually educate each user until you have a critical mass. Then you need to market and hype your product. So that developers will tell each other how cool your new technology is. Continue with that a few years until there are code in production that use your product, before even thinking about a business plan. So there are few options, either you have enough money so that you do not have to "work" again, and can spend your time making new tools. Or your current employer lets you work on the tools. For a startup working on developer experience (language and tools) I would suggest a 10 year runway (funding) and that 1/3 of the budget goes into educating users and 1/3 goes to marketing.

Any software business that is profitable, already have code in production, and that code need to be maintained. So instead of creating a new better experience, you can make the current experience better. eg. putting rockets on a horse, rather then creating an automobile.

Re: Developer Experience: Fundamentally harder than normal UX

#15

Post by wruza »

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 evils. Not only they diverge with new versions of everything, but there is a constant attention switch (stacks of them!) and unnecessary diving into things that may or may not be important to the development process. There is no way to omit these checks when you learn or return to an idle project.

I have a long time idea that every config, format, api call, and so on should come with inseparable documentation ui (+rationale, examples of use, best practice links, pre-configuration, diff/merge views, etc). Yes texts are simple and easy to read, but we also write. You can make text from a structure in O(1), but you cannot make a knowledge from an empty file in O(sensible), for any sensible sensible.

Not arguing on salaries though. Even pretenders who have no clue can take a great cut off this nonsense.

Re: Developer Experience: Fundamentally harder than normal UX

#17

Post by wruza »

grahamlee wrote: post #7

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…

Isn’t that a circular feedback that leads nowhere? Developer like to be developers but being one doesn’t mean to make solutions and profits. Like a bureaucrat likes bureaucracy and then everything is bureaucracy under the hood sprayed with marketing sauce. Best stories of best products sound “we hacked, broke, short-cutted, ignored, made a fucking lots of money, and then rewrote fundamental instruments to match our needs”. Isn’t there a controversy with a nice cool environment that developers praise?

Re: Developer Experience: Fundamentally harder than normal UX

#18

Post by Gehinnn »

ailideex wrote: post #11
Gehinnn wrote: 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…

Did you read about vi before? How do you know all the shortcuts?

Re: Developer Experience: Fundamentally harder than normal UX

#19

Post by alxlaz »

Far from me to defend every UI of every development tool out there but I think statements like these, and their illustration, could benefit from some explanation for those of us who are not designers:

> We coders still put up with horrid UX/UI when programming.

which is illustrated with a screenshot from Visual Studio... .NET 2002, I think, judging by the application icon?

Setting aside the relevance of a 20-year old screenshot, what exactly is wrong with that interface and what makes it horrid? I mean it definitely had its quirks but:

- It's spectacularly compact, certainly way better than anything I've seen in the last five years. We could display an UI builder and the associated code on single 1024x768 screen and work on it semi-comfortably. "Beautiful" UI/UX, as understood today, is so cluttered by whitespace (oh, the irony...) that it's barely usable on a 1920x1080 screen. A similarly compact interface on today's huge screens would be a dramatic productivity improvement that, twenty years ago, we could only dream of.

- You could easily access any function through textual menus -- no hamburger menus, no obscure, monochrome icons. Granted, the toolbar icons were a pain, but the way I remember it, most of us either disabled it straight away, or just populated with a couple of items that were of real value and which we knew well.

- The colors have great contrast, the whole thing is readable even on a very poor-quality screenshot that seems to have been actually downsized.

- UI items have enough relief and/or distinction that it's clear what you can interact with and what you can't (maybe the item palette from the diagram editor is an exception, or at least the screenshot makes it look like one, but virtually every program in that era made it look like that so it wasn't so hard to use).

So what's wrong with that thing?

Re: Developer Experience: Fundamentally harder than normal UX

#20

Post by rolleiflex »

kurnikas wrote: 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 this, and those who do got it the long way round — by working on products that have a lot of essential complexity, like AdWords, and by repeatedly fighting those battles

b) An engineer's operating environment, OS, IDE, shell, terminal, is a reflection of the inside of his or her mind writ large. Like every Jedi has to build their own lightsaber, every engineer has to go through this pain of building out their weapon, because one's workflow is how one thinks, how you look at the problems at hand. No UI designer can help with that.

[0] (Because it's relevant to the context: ex-Google, ex-Facebook as professional experience)

Post reply on HN