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

101–110 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#101

Post by ripley12 »

Glench wrote: post #36

To make some of the ideas in this article a little more concrete, here are some research demos I’ve made: * Legible Mathematics, an essay about the UI design of understandable arithmetic: http://glench.com/LegibleMathematics/ * FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: http://glench.github.io/fuzzyset.js/ui/ * Flowsheets V2: a prototype programming environment where you see…

I really love your Flowsheets prototype, I hope someone pursues that direction in the future. “Spreadsheets with more tools from traditional programming” seems like such a powerful idea.

Re: Developer Experience: Fundamentally harder than normal UX

#102

Post by werg »

yoshyosh wrote: post #70

I think developers are missing the testing practices UX designers have grown accustomed to: 1. Usability tests where developers literally sit down and watch someone install and use your library from scratch (I find a lot of developers do not like to do this). Things like, seeing where they have to look up documentation (and how they do it), what bugs they hit, and how often they make common mistakes. I think a lot of…

I couldn't agree more!

Why doesn't every error message have a link to a specific page with discussions, instructions, etc. Or maybe even a button you can click where the machine tries a best guess at an automatic fix?

Re: Developer Experience: Fundamentally harder than normal UX

#103

Post by werg »

scroot wrote: post #58
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…

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, "progra…

We need to find our equivalent of a printing press! For what it's worth, possibly that won't be just one thing, but a wide array of tools?

Re: Developer Experience: Fundamentally harder than normal UX

#104

Post by werg »

regularfry wrote: post #45

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.

Interesting, what example would come to mind?

Re: Developer Experience: Fundamentally harder than normal UX

#105

Post by werg »

ChrisMarshallNY wrote: post #12
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. Mock…

Too often, "tests are required" -- but as you say it's very hard to test anything meaningful, so developers "test something" and call it a day.

Re: Developer Experience: Fundamentally harder than normal UX

#106

Post by werg »

Gehinnn wrote: post #5

I think that improving DX might be the most important thing of the future software industry. If a single developer devotes his live to a better DX, hundred of thousands of developers might be significantly more productive. 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 f…

What a cool extension! I'll give it a whirl!

On impact: I've been running the numbers for a tool I'm working on and the projected savings for the industry look insane! Just by shaving off 10 minutes here or there you can contribute a lot.

Re: Developer Experience: Fundamentally harder than normal UX

#107

Post by werg »

azhenley wrote: post #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

Thanks for posting this! So happy to see some real academic interest in these topics!

Re: Developer Experience: Fundamentally harder than normal UX

#108

Post by scroot »

werg wrote: post #103
scroot wrote: post #58

Earlier quoted context omitted.

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, "progra…

We need to find our equivalent of a printing press! For what it's worth, possibly that won't be just one thing, but a wide array of tools?

> For what it's worth, possibly that won't be just one thing, but a wide array of tools?

We need to think hard about what reading and writing really are. These are the only technologies of their kind and they have had a completely different kind of qualitative effect on individuals and whole societies than other types of media and/or technical systems.

It brings up interesting questions. If you have a scribal culture, what are the interests of the community of scribes? Would they support easier writing systems, more amenable to learning by outsiders, or something more arcane that protects their cultural and social position (or something in between)?

Also what is the transition from one literate state to another like, what does it entail, how long does it take, and what kinds of "works" appear in the interregnum? In the Middle Ages the Universities in the west were largely concerned with endlessly rehashing Aristotle (a thinker on the border between orality and literacy) over and over, without coming up with original ideas. Is the enclosed community of developers today more like the scholastics than they'd care to admit?

There are stark differences between systems like Unix and those hinted at by Hypercard, Oberon, Smalltalk and the rest. It's like we know about the alphabet and what it is capable of, but the cultural inertia of complex cuneiform systems is too much to get past.

Re: Developer Experience: Fundamentally harder than normal UX

#109

Post by MrEldritch »

Glench wrote: post #36

To make some of the ideas in this article a little more concrete, here are some research demos I’ve made: * Legible Mathematics, an essay about the UI design of understandable arithmetic: http://glench.com/LegibleMathematics/ * FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: http://glench.github.io/fuzzyset.js/ui/ * Flowsheets V2: a prototype programming environment where you see…

These are very interesting! The Legible Mathematics one also made me think of APL, which is very hard to read - but specifically it's hard to read for the same reason that traditional linear programming math is hard to read, the lack of visual grouping[1]. I wonder how it might be possible to redesign something like APL to take advantage of rich text and more complex formatting?

[1] The weird symbols might seem like an initial barrier to this, but they're only hard to read if you're unfamiliar with APL; they're actually very easy to learn and remember, as there's not that many of them and they all do very basic operations. However, APL loves operator overloading and likes to give operators different functions based on whether they're used in prefix ("monadic") or infix ("dyadic") forms, and there are also higher-order operators that consume the operators immediately adjacent to them and then operate on the expressions after that; all of this makes the nominally right-to-left parsing require a fair bit of mental effort instead of being able to rely on immediate visual recognition.

Re: Developer Experience: Fundamentally harder than normal UX

#110

Post by ChrisMarshallNY »

henrikeh wrote: post #96
ChrisMarshallNY wrote: post #12

Earlier quoted context omitted.

> 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. Mock…

Just a question. Do you imply that the mock of a device should simulate/emulate the entire behavior of the device? Because you definitely don't need to do that and it would, of course, be a vast and hard-to-justify endeavor. You only need to _mock_ the object, that is emulate behavior on a small scale.

Yes and no.

It depends on what we are testing.

It can actually be worse than useless to rely on the "perfect world" of unit testing. I have had a nasty shock, when switching from mocked behavior to real-world behavior. I write about that here: https://medium.com/chrismarshallny/concrete-galoshes-a5798a5...

Post reply on HN