
Developer Experience: Fundamentally harder than normal UX - werg
https://www.gabrielpickard.com/posts/developer-experience-fundamentally-harder-than-normal-ux/
======
Glench
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/](http://glench.com/LegibleMathematics/)

* FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: [http://glench.github.io/fuzzyset.js/ui/](http://glench.github.io/fuzzyset.js/ui/)

* Flowsheets V2: a prototype programming environment where you see real data as you program instead of imagining it in your head: [https://www.youtube.com/watch?v=y1Ca5czOY7Q](https://www.youtube.com/watch?v=y1Ca5czOY7Q)

* REPLugger: a live REPL + debugger designed for getting immediate feedback when working in large programs: [https://www.youtube.com/watch?v=F8p5bj01UWk](https://www.youtube.com/watch?v=F8p5bj01UWk)

* Marilyn Maloney: an interactive explanation of a program designed so that even children could easily understand how it works: [http://glench.com/MarilynMaloney/](http://glench.com/MarilynMaloney/)

~~~
henrikeh
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).

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

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

------
kurnikas
> 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 we
should make a developer tool with the same level of "immediate familliarity"
that we try to build into a website where customers will bounce easily, for an
audience who is willing to spend time learning a tool if it provides value to
them.

~~~
ailideex
Maybe a bit unrelated, I got used to Windows 2000, then window XP, then Gnome
2, then Gnome 3 came. So I stuck with Gnome 2, then moved to XFCE, and now
with RHEL 8 I had to use Gnome 3 because there were no other options. Gnome 3
is an absolute horror show. I don't know who made it, for who, and what the
theory behind it is but I don't see how it would be easier to use for someone
non technical, my parents both understood how to use Windows 2000. It is just
weird. It is harder to multitask as efficiently as I did in XFCE and Gnome 2.
Gnome 3 is not simpler - it is just more convoluted.

And I feel this is a very similar situation with other tools. I edit code with
vim, in a terminal. This is simple as dirt. I do it because it is simple as
dirt. Visual Studio is incredibly complicated to me because to do the creating
code part my job I need to understand the following:

\- How code is built.

\- How to build the code without using any graphical front end.

\- But now when you bring VS into the mix I need to also understand visual
studio. It does not remove complexity, it adds it.

Similar thing with debugging, I need to understand all the ins and outs of
debugging but now bring VS into the mix and I need to understand it's stupid
UI.

I like simple, my mind is simple. I can learn things, if there are rules and
patterns it makes it easier to learn, but the less things I have to learn the
happier I am. I don't have an option to not learn some things, like how to do
build automation, how to debug code, how computers work, etc. But I do have an
option to not learn something entirely useless like VS.

I think the lie being sold is that somehow you can be a programmer without
actually knowing how to use a computer. And to know how to use a computer is
not the same thing as knowing how to click on things in the UI with a mouse.
To know how to use a computer you need to understand how to use it to do
automation - and once you need to do this VS is just a nuisance.

Just a rant I guess.

~~~
de_watcher
VS is great for visual debugging, the build was secondary: you set it once and
forget. But it only worked in the era of the proprietary software because you
didn't have much third-party stuff to link into your project. Testing has
changed too: you'll write an automatic test anyway, which means that the
software is shaped for debugging by writing tests.

~~~
ailideex
VS is decent at debugging if it does not fall apart in the process - which for
me happens more often than not. So not really useful.

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

~~~
meddlepal
I think of most UX designers as children: they want everything to conform to
the latest trends and are always in search of the new shiny thing to play
with.

~~~
alxlaz
Having worked with designers since back when Visual Studio .NET 2002 was
pretty fresh, I think this is a very over-simplified assessment and I don't
think it's fair.

There are definitely cargo cult designers, just like there are cargo cult
programmers out there. But I don't think that's true of most designers, just
like I don't think it's true of most programmers.

Chasing the latest trend isn't always a decision you make by yourself, and
isn't always a decision you can oppose on your own terms.

Virtually every designer who was in the industry ten years ago or so can come
up with a good design that's 100% against the latest trends -- contrasting,
non-flat, compact, whatever.

But it'll get shot down within minutes in any product design meeting.
Sometimes by people who have zero design experience, so they can't judge a
design _except_ by how well it conforms to the latest trends. Sometimes by
people who lack the "political" capital to argue for an original design with
their bosses, too. There are a lot of factors here, and most of the time the
people who do the designs have the least amount of influence.

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

~~~
regularfry
But this is exactly why Rails did so well. The developer experience was _good_
, right off the bat, in a way that a 15 minute video could portray so that
developers _could_ instantly see the benefits. There was no "manually educate"
step taking months.

~~~
werg
You are so right, those "build a website in 15 minutes" demos hit like a bomb
back in the day!

------
hinkley
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
only better than your input by degrees.

I’m not sure there would be much fine woodworking at all if the best
woodworking tools were only as good as the best software tools. There is no
Lee Valley of developer tools. You can’t make me stop using JetBrains
(individual licenses were their best idea every), but it still doesn’t rate
above a Woodriver, and if I’m honest some of their stuff is Stanley level, and
not even the antique stuff. And their stuff is better than just about any
other tool I use all day.

I suspect Harbor Freight could make better software than Atlassian, and I
don’t even mean that as a metaphor. I think I could take harbor freight
employees and get better requirements out of them because they wouldn’t be up
to their ears in cognitive dissonance.

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

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

------
grahamlee
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 developer experience because, as
developers, it's what we experience.

We accept the heritage of developer tools - the keyboard-driven interface that
displays to a teletype emulator, the edit-compile-debug workflow - and build
tools that improve the processes that have built around those legacies. This
is why when something comes out of left field like Adele Goldberg and
colleagues describing Smalltalk, we find it easy to adopt the approach to code
organisation on offer and hard to adopt the image model, browser-based
workflow, debugger-driven iteration, and other changes.

Meanwhile, when we go out into other domains, we use a little bit of
understanding of that domain, a lot of reasoning by analogy, and an intention
to "disrupt" what already exists and "eat the world", and create something
that works very well for the spherical user in a vacuum without all of the
detailed understanding that comes from having grown up in the system and
learnt from people who grew up in it even longer ago.

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

~~~
werg
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?

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

------
jussij
> There has been tremendous growth in the field of UX/UI. Without a doubt,
> today's applications are much more user-friendly than those from 30 years
> ago. Back then, users were given features, interface be damned.

That 30 year time frame takes us back to 1990 and back then the user
experience was limited by the technology of the time.

However a decade later we had Windows XP.

I would say that 20 year old Windows XP might in fact be a much better user
experience than the modern UX/UI we have to live with today.

The much less powered CPUs of that time felt much more responsive than the
modern day CPUs/OS that we have to today.

------
pjc50
> How do I run this thing? Where does the code start? Is my system configured
> correctly?

This is why there are occasional spasms of "back to basics" or plaintive
remembering of the BBC Micro. You power it on, it beeps, and within a second
you're in the interactive development environment. Typing code runs it
directly. Typing code with a line number adds it to the program. No
configuration, containers, downloads, updates, dependencies or uninformed
choices to make.

> Why do we treat this as a moral failing instead of a usability issue?

Yes. This applies in so many places. Learn from "Poka-yoke". The system should
make it easier to do safe things and harder to do unsafe things.

> Tests are a usability dead end

Depends what you mean by "tests". A strong type system does away with certain
categories of test (and conversely a lot of the heavy unit testing usage comes
from communities with weakly typechecked languages). But both types and tests
are capturing a human-level requirement of "if X then Y", a constraining of
the problem space.

This is why many successful code archaeology maintenance projects start by
building a test suite to capture the current functionality of the program. An
executable requirements document.

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

I'm not quite sure what the author is arguing for here in particular.

Anything that makes writing tests a bit easier, e.g. suggestions for
additional test cases, would be cool, but ultimately tests are about writing
down your assumptions/expectations about the code.

No, they are not formal proofs and sometimes they are not perfect but they
still provide a lot of value. So far I haven't found a good reason not to
write tests (since I outgrew my newcomer attitude) and yeah integration tests
are usually what I focus on most. For any case where testing whole systems
today is hard, there are some fundamental challenges (e.g. end to end web UI
test). I don't quite see how tooling will get rid of the need for tests.

~~~
ChrisMarshallNY
> 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...](https://medium.com/chrismarshallny/testing-harness-vs-
unit-498766c499aa)

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

~~~
ChrisMarshallNY
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...](https://medium.com/chrismarshallny/concrete-
galoshes-a5798a55af2a)

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

------
Gehinnn
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 find it granted that everything
is free. They would rather hire another developer than paying for licenses
that might effectively increase the effiencency of the developers they already
have.

[1] [https://github.com/hediet/vscode-debug-
visualizer/blob/maste...](https://github.com/hediet/vscode-debug-
visualizer/blob/master/extension/README.md)

~~~
yoshyosh
Just a little bit of feedback, while the visuals are quite nice I think this
page could be helpful if treated like a landing page, what's the problem/why
is this helpful compared to what I currently/normally do. I might not be the
target audience though, since I don't understand what it does/why it helps
quite quickly through scanning

------
wruza
This. Despite latest <libname>-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.

~~~
chii
> but you cannot make a knowledge from an empty file in O(sensible), for any
> sensible sensible.

why isn't a schema and then auto-complete a sensible way to do config?

Both xml and json has a schema file that you can create generic text editors
with auto-complete for.

------
edent
I taught Scratch to kids. They love the visual element of the language. It's
so hard to make basic mistakes - partly because you _can 't_ put an Int where
the code expects a Bool.

The interface shows you all the components you can use, and what data they
require.

I then move on to teaching Python, and watch kids get frustrated.

Languages like DRAKON should be the future of our profession - not typing 80
char lines into a terminal.

~~~
werg
The question is: how do you grow up from there, in terms of expressive power?
I.e. is it possible to find more middle ground between Python and Scratch?

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

------
koffiezet
A site about UX that uses a fixed-sized font with horrible spacing? This I
about the worst website UX I can imagine... Long live reader view...

~~~
werg
Haha, I agree. Sorry.

------
dusted
I can't be the only one who prefers the way applications looked 30 years ago?
When they dumped whatever they had to offer right there for you to explore and
pick from. These days everything is hidden below a million layers, trying so
hard "not to be in your way" that you need a deep love of pixel-hunt-point-
and-click adventures to get anything done..

Let's take an example: Specifying DNS servers in Windows. 95: 1\. Rightclick
"Network" on desktop -> Properties 2\. Doubleclick on the TCP/IP protocol for
the NIC. 3\. Type new DNS server. 4\. Press OK.

10: 1 Press start 2 Search for control panel 3 Open Network and Internet
settings 4 Select Change Adapter Settings. 5 Rightclick NIC and select
Properties 6 Select TCP/IP and then Properties. 7 Type new Server 8 Press OK

Sure, some may think that Windows 10 looks better than Windows 3.11 or 95, but
I don't and I can't believe everyone does.

------
yoshyosh
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 this could be logged e.g. A developer signs up, you
have their email + API key, you can connect the dots between what doc pages
they view, how often, and what errors they commonly run into.

2\. Doing whatever it takes to minimize the time to aha moment. This is
absolutely critical for any product design effort, but not many companies
measure this if any at all when it comes to DX. I think Twilio and maybe
Stripe are the only ones that may have had this as a key onboarding KPI.

Ultimately I think a majority of developers that are capable of implementing
these things are quite technical and used to the general state of DX so they
don't view bad DX as much of an issue unless its really terrible.

Lastly, I really wish error messages would just be super informative. For
example getting something like this "undefined method `my_method_name' for
nil:NilClass (NoMethodError)" still feels a bit cryptic to someone newer to
programming, if you can also tell me the human readable variable that I used
that caused this issue, the one that was nil, and the exact line (the stack
trace purely by itself can be confusing) that little touch would go a long
way. For example compare that error message to something highlighted in a
different color that says "The variable you used called "contact" on line 87
was found to be nil, this is likely causing this issue". This way when you run
into the error and are scanning the stack trace, the computer is telling you
as quickly as possible what may be wrong, again for a novice since the way the
original error is written for someone more experienced is likely succinct
enough.

~~~
werg
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?

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

I mean, fairly often throughout the years. Particularly in communities for
lisps, ruby, perl, python, C. More common 5-10 years back perhaps.

Relevance is a fairly common topic across the board. Discoverability is maybe
the least common topic here, and one that's a pretty interesting one for PL
design imo.

I haven't seen too many _blog posts_ about these things lately, but they're
frequent enough discussions in personal circles and in mailing lists/chats
that this question seemed odd to me.

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

~~~
werg
Interesting, what example would come to mind?

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

------
boomlinde
I wouldn't say it's fundamentally harder. It's fundamentally the same thing,
because developers are users, and software development isn't the only domain
where users have discerning tastes and needs that they want catered to. It's
not the only domain where users will happily accept a steep learning curve for
the years of use that will pay off that initial investment, or where shoving
detailed information under the carpet can be a negative thing.

I think it would be arrogant to think of software development as exceptional
in this sense, but it's certainly reflected in a lot of software designs. The
reality IMO is that if you aren't working off a set of insights and
observations like the one listed in the article—regardless of your users'
domain—you aren't making enough of an effort to design for your users.

------
_pmf_
You think it is harder because you are not familiar with the depth of non-
developer workflows. Developer hubris.

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

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

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

------
raxxorrax
I wish we could scrap the term experience again and just go back to interface.

I connect experience with hyped concepts that are already forgotten today.

That said, tendency to decrease choice seems to only serve certain users.
Other feel just as restricted as developers, which are also users, so the
dichotomy should be questioned.

------
azhenley
"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](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](http://web.eecs.utk.edu/~azh/blog/guidehciseresearch.html)

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

