Live data from Hacker News

Developer Experience: Fundamentally harder than normal UX

gabrielpickard.com

111–120 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#111
post #99
post #6

I told my UX buddy half a dozen years ago that I was optimistic that there seemed to be a glut of UX people coming because we were going to steal a bunch of them to look at DevEx issues. I spent some time nerding out over woodworking hand tools a few years back and it pretty well cemented for me something that I’ve suspected for most of my career: people down in the muck have very limited vision. That your output is…

Atlassian truly is the Harbor Freight of developer tools! I'm a bit hopeful that DX might finally start getting the love it deserves. -- For better or worse, Microsoft seems to understand the potential that lies in building better tools and seducing programmers to join their fold.

Disclosure: I used to work for a competitor. Some of my coworkers were afraid of Atlassian and it rubbed off on me.

Later when I used their stuff and could be (more) objective, I was sort of confused by that previous experience. They're... okay. If that was intimidating maybe that said more about us than about them.

I am probably experiencing a little backlash when I react to their shenanigans because they are not 'all that'. At all.

Trac (no affiliation) is ugly but like your favorite hammer. It is probably the least painful project management suite I ever recall using. And I used it before they decoupled their parsing and rendering logic, so writing plugins that involved anchor tags was a warren of duplicated code.

My last musing-while-brushing-my-teeth was to wonder what would happen if someone drop-kicked the Trac CSS files and wrote a new one from scratch using modern conventions.

Re: Developer Experience: Fundamentally harder than normal UX

#112
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…

Great experiments/demonstrations.

What are your thoughts on Mathematica/Wolfram Language? Some of these ideas are present in it (like mathematical typesetting, interactive documentation and live code/data updates).

Re: Developer Experience: Fundamentally harder than normal UX

#113
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…

Great experiments/demonstrations. What are your thoughts on Mathematica/Wolfram Language? Some of these ideas are present in it (like mathematical typesetting, interactive documentation and live code/data updates).

I don’t know much about it. From what I’ve seen it looks like something Stephen Wolfram can use really well but I wonder if other people are able to use it.

Re: Developer Experience: Fundamentally harder than normal UX

#114

Earlier quoted context omitted.

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

I'm not going to argue against your experience and from reading the article it seemed like you made the right call. Perfect world testing is indeed a failure, but I would say that "imperfect" world testing is exactly where mocking is beneficial, because it can reliably produce all sorts of anormal behavior. But again, it obviously depends on the situation and circumstances, and good design probably removes more errors than good testing.

Re: Developer Experience: Fundamentally harder than normal UX

#115
post #113

Earlier quoted context omitted.

Great experiments/demonstrations. What are your thoughts on Mathematica/Wolfram Language? Some of these ideas are present in it (like mathematical typesetting, interactive documentation and live code/data updates).

I don’t know much about it. From what I’ve seen it looks like something Stephen Wolfram can use really well but I wonder if other people are able to use it.

I think it has its merit. It is a very _designed_ system which is definitely a side-effect of Stephen Wolfram's attention to it. But despite it being a bit of a singular vision, I do think that it presents a very complete idea of what a programming/computer interaction environment can be. For example it is like Lisp in that it is homoiconic and the whole interface, layout/formatting, the file format and everything builds upon this.

Re: Developer Experience: Fundamentally harder than normal UX

#116

Earlier quoted context omitted.

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

Addendum: can someone tell me what's wrong with using software developer as a description of what we do?, why do we need to borrow other professions titles?, it's because we want more respect?

I've always referred to myself as a Developer, as my degree is Info Tech, not Engineering.

I'm not an accredited engineer, so I feel I have no right to the title.

It really annoys me that some manages at work call themselves Release Train Engineers.

Re: Developer Experience: Fundamentally harder than normal UX

#117
post #104

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?

This line seems to sum up the core of the complaint:

> When was the last time you heard of a programming language discussed in terms of discoverability, succinctness, relevance, let alone beauty?

The ruby-lang mailing list used to be full of these sorts of discussions. If the author hasn't come across these factors being spoken about, that says more about the social value systems around the dominant ecosystems than about any fundamental complexity. Ruby lost the PR war to JS.

> Coding tools were around before UI/UX was a thing...

...yeah, no. At least, not in a way that makes the author's point. COBOL was an attempt to improve the developer experience. UI research predates JS by decades.

This paragraph approaches the complexities in JS as though they were a natural consequence of when JS was written, as though it wasn't possible to have done any better so we've all got to live with the best that was available then, rather than what we know now. That's just not true. JS even when invented wasn't a good language. Brendan Eich wanted to write a Scheme, and we'd all have been better off if he'd got away with it, and also if he'd had more than 10 days to implement it. The things we complain about in JS were commonly known to be bad at the time, they just didn't end up fixed for reasons entirely unrelated to the technology.

Re: Developer Experience: Fundamentally harder than normal UX

#118
post #86

Earlier quoted context omitted.

Indeed! Compare to CAD or Photoshop for deep, complex workflows.

I was wondering about this -- but how would CAD or Photoshop be more than a Context Free language? In particular, consider Feature Structure Grammars which are equivalent to CFGs and can really capture a lot of inter-context agreement without needing to be Context-Sensitive. I certainly may be wrong though, all sorts of stuff ends up being Turing-Complete.

They can be, and afaict, are, typed context sensitive languages.

Re: Developer Experience: Fundamentally harder than normal UX

#119
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…

I digress but I am really interested in your experience as both dev and design as I am going in this path too.

How did you juggle acquiring skills for both roles? Also, where there times you had to struggle between the two mindsets on a task?

Re: Developer Experience: Fundamentally harder than normal UX

#120
post #32
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…

Rich Hickey has a pretty interesting take on this very topic where he compares programming languages to instruments, and how instruments aren’t for beginners. How it takes work to become good at playing an instrument, and how that isn’t a bad thing. > But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you d…

> Imagine if you downloaded something from GitHub and it gave you blisters

You mean Haskell?

Post reply on HN