
Programmers are not different, they need simple UIs - dwaxe
http://antirez.com/news/107
======
PaulHoule
One problem is that people are too macho to admit they have cognitive limits.

I know people in the finance business who are sending their CTO's out to take
the Series 7 exam because to write code for some domain you need to understand
something about the domain. That is on top computer science principles, your
programming language, the "standard library" for your programming language,
libraries you use on top of that, your build system, your version control
system, and all kinds of stuff.

And now people think they are going to be left behind if they don't learn
Angular, Rust, Shiny7 and all of that.

Every bit of bullshit steals your cognitive capacity and turns you into an
0.1x programmer.

~~~
beat
As an artist as well as a programmer, I've learned a lot about the techniques
of professional artists. Most are specialists, not generalists. They have a
specific, focused toolbox, and they _do not leave it_. If a guitarist gets
_that_ sound from _this_ guitar and amp and pedals and scales and rhythms, he
sticks to that. If a painter prefers these subjects and those brushes and
paints and canvas sizes, she sticks to that.

Become proficient in a medium to the point where absolutely no conscious
thought is required to use it to its fullest extent. That's the secret of
great artists.

Apply that to programming, now. You can learn a field and the core tech of the
field, and get a lot done for a long time. Or you can go chasing the new and
shiny every six months and drive yourself up a wall and spend all your time
_learning_ instead of _making_.

~~~
kecks
What if you make your core competence as a programmer "gaining steady footing
in new tech", along with basic like code structuring, version control and some
automation (CI/testing etc.)?

That way you might not become "the greatest X86 assembly programmer" or
whatever niche you like, but you might become a very proficient system
integrator, which is useful in its own right.

~~~
beat
Oh, that's me. I'm a mile wide and an inch deep. So I can do a lot of things,
most of them not very well. My niche friends are _much_ better than I am at
anything I can do, but I can do a lot more things.

It's worked out kind of weird, pushing me (after a long career) into being a
founder, and building a tool for generalizing common problems in systems
integration. :) My desire to wear lots of hats finally works! But really? I'm
more or less a specialist at being a generalist. And I've _learned_ not to
chase shiny new tools, because they're very distracting.

~~~
fapjacks
I'm the same way! I try to get good at something, and then immediately move
on. I am the best at nothing, and better than almost no one. But I am the only
person I know that can write code, swordfight, surf, use a ham radio, play a
handful of instruments, build things out of electronics, draw and paint,
shoot, blacksmith, and blow glass (all at the same time -- just kidding)! I
make myself very happy by being able to try something and then practicing
until I get "good" in my own opinion. It's absolutely true that up against
pros I am pretty terrible! I have also come to understand over the years that
this is a byproduct of having a hacker mentality. I am loathe to use that word
in reference to anything I am or anything I do, but that's just what I see.
Hackers are curious creatures, and so it follows that they can do a lot of
things.

~~~
Retric
It's often really hard to judge how skilled you are at something.
[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
is overblown, but being able to say do a crappy weld in 4 hours that a
competent person can do better in 15 minutes is often just dangerous. Many a
handyman has caused 20,000+$ worth of damages or gotten someone injured.

That said, hobbies don't need to be productive and half assing something is
often good enough. Yes, a simple wedge doorstop may damage the door, but well
sometimes that's just not an issue.

~~~
fapjacks
Did you mean to reply to my post?

------
pavlov
_... I want to stress how important is the concept of simplicity, not just in
graphical UIs, but also in UIs designed for programmers._

I've always felt sad that this dichotomy is so strong in our industry. There
are graphical tools for proles and then there are text-based tools for
programmers, and never the two shall mix.

It didn't have to be this way. Smalltalk was an integrated graphical system
for both programmers and users already 40 years ago. Something like the
Smalltalk class browser with visual editing of live code would feel
revolutionary even today compared to most of the systems we have.

But we're seemingly stuck with another '70s approach, that of Unix: streams of
plain text, UIs based on undiscoverable and inconsistent command line argument
arrays, all glued together with a spider's web of incredibly fragile string-
replacement tools like shell scripts and templates.

~~~
IshKebab
Agreed. Mostly a result of "if I had to learn it so should you" and stuck-in-
the-mud attitudes.

Look at the Linux systemd / init debate. Despite the fact that sysvinit is
clearly ancient, awful technology there are still people who have spend time
learning it and don't want something better.

Another example: bash. Clearly an awful awful language/shell but it sticks
around because too many people can't admit that _the thing they know is
rubbish_.

~~~
EdiX
> Another example: bash. Clearly an awful awful language/shell but it sticks
> around because too many people can't admit that the thing they know is
> rubbish.

You should try thinking about what a better bash would look like, it's not as
simple as you make it to be. I think the best I've seen in this direction is
rc and I think that's still not enough to compensate for the loss of ubiquity.

The stuff people come up when they try to "redesign the unix terminal"
(usually some javascript contraption) is always extremely lacking.

~~~
IshKebab
It's not simple, but it's not hard to imagine. Some of these things exist
already:

* Image support (I can't remember where I saw this but it exists)

* Structured data piping (in Powershell)

* Machine-readable command-line arguments, which would enable...

* ...Proper autocomplete (like in IDEs)

* Real types (Bash is 'stringly typed')

* Sanity (e.g. look at how `[` is implemented in Bash; none of that)

* A better way to integrate with programs than running them on the command line (e.g. shell bindings).

That last one would be tricky and really requires moving away from the C ABI
as the Lingua Franca of libraries. That is probably quite far away in the
future unfortunately.

~~~
icebraining
Regarding (1), a proposal that had some impact was TermKit[1], which was
supposed to auto-detect the type of data coming from stdout and display it
intelligently. It died on the vine, though[2].

[1] [http://acko.net/blog/on-termkit/](http://acko.net/blog/on-termkit/)

[2]
[https://www.reddit.com/r/programming/comments/137kd9/18_mont...](https://www.reddit.com/r/programming/comments/137kd9/18_months_ago_termkit_a_nextgeneration_terminal/)

------
adriancooney
I honestly believe this is the reason why React is currently winning the web
tech wars. The API is minimal, clear and concise. Once you've mastered the few
functions and concepts, you rarely have to reference the documentation and
understand what tools you have to solve a problem. A major source of
frustration with me as a programmer is implementing something only to find the
library or framework I'm using has already included it in its core, it's just
not in the documentation or hidden in a huge API reference. It's a refreshing
experience when libraries and frameworks appreciate the product and the
programmer.

~~~
dc2
I can't necessarily agree with this, as while React itself is very simple, you
will find that after sufficient experience with it in the real world, you need
its ecosystem and surrounding libraries, and this can be absolutely daunting
for some.

e.g. NPM, Webpack, Flux/Redux, React-Router, Thunk, DevTools, CSS, etc.

~~~
zxcvcxz
But compared to something like angular react is minimalist.

~~~
simplify
But compared to something like GWT, angular is minimalist :) Surely that
doesn't mean we should all settle with angular, does it?

------
mbostock
This sentiment—that application programming interfaces are user interfaces,
and that programmers are users—is why I’m spending so much effort improving
the API of D3 4.0. I wrote about that in March:
[https://medium.com/@mbostock/what-makes-software-
good-943557...](https://medium.com/@mbostock/what-makes-software-
good-943557f8a488)

~~~
blakeyrat
Please consider making it easier to _debug_ as well. JavaScript has some
excellent debuggers available to it-- D3 (at least the older version I used)
seemed almost designed to defeat every useful feature of those debuggers.

~~~
mbostock
It’s interesting—or frustrating?—that you should mention this, because D3 _is_
explicitly designed with debugging (and debuggers, developer tools) in mind.
I’d like to understand your frustrations better.

There are two main strategies that D3 uses to facilitate debugging.

First, whenever possible, D3’s operations apply immediately; for example,
selection.attr immediately evaluates and sets the new attribute values of the
selected elements. This minimizes the amount of internal control flow, making
the debug stack smaller, and ensures that any user code (the function you pass
to selection.attr that defines the new attribute values) is evaluated
synchronously.

This immediate and synchronous evaluation of user code is in contrast to other
systems and frameworks, including D3’s predecessor Protovis, that retain
references to your code and evaluate them at arbitrary points in the future
with deep internal control flow. I talk about this a bit in the D3 paper (and
the essay I linked above):
[http://vis.stanford.edu/papers/d3](http://vis.stanford.edu/papers/d3) Even in
the case of transitions, which are necessarily asynchronous, D3 evaluates the
target values of the transition synchronously, and only constructs the
interpolator asynchronously.

Second, and more obviously, D3 uses the DOM and web standards. It doesn’t
introduce a novel graphical representation. This means you can use your
browsers developer tools to inspect the result of your operations. Combined
with the above, it means you can run commands to modify the DOM in the
console, and then immediately inspect the result. D3’s standards-based
approach has also enabled some interesting tools to be built, like the D3
deconstructor:
[https://ucbvislab.github.io/d3-deconstructor/](https://ucbvislab.github.io/d3-deconstructor/)

~~~
blakeyrat
It's been awhile since I had to use it, but I recall the most common
frustration from me was getting an unhandled exception with a call stack like:

AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod ->
AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod ->
AnonymousMethod -> AnonymousMethod

Occurring hours after I'd actually created the code that caused the exception.

Since I've moved jobs since then, I can't give a more specific example, sorry.

> that retain references to your code and evaluate them at arbitrary points in
> the future with deep internal control flow.

For the record, that appears to be exactly what was happening to me when I was
struggling with D3.

~~~
mbostock
Without a more specific example to go on, it’s difficult to speculate. The
only case where you’d get an error asynchronously should be in the case of
transition.tween or an event listener—cases where the code is necessarily
asynchronous—and not something like selection.attr or transition.attr, where
the code can be evaluated synchronously.

It’s true that D3 uses closures and anonymous functions internally. But
assuming you are using a debugger and the non-minified code, you can use that
debugger to see exactly what the code is doing. To continue with the example
of selection.attr, the implementation is here:

[https://github.com/d3/d3-selection/blob/master/src/selection...](https://github.com/d3/d3-selection/blob/master/src/selection/attr.js)

So a typical call stack would be three deep: selection.attr > selection.each >
attrFunction’s closure.

------
pathsjs
I completely agree with the sentiment. And this is why such a statement made
by antirez leaves me puzzled.

I admire Redis for its performance and simplicity of setup, but if there is
one thing that Redis does not have is a coherent API.

Whenever I use Redis, I absolutely need the command cheatsheet, as it seems
that every command works differently. There is no commonality in data
structures. The whole thing seems more dictated by the underlying
implementation than the desire of providing a simple API.

For instance, why LPUSH accepts multiple parameters but LPUSHX does not? Why
there is even hyperloglog in a database? Where did the need for RPUSHLPOP come
from? Why the options for SCRIPT DEBUG are YES, SYNC and NO?

I don't want to be too negative. I appreciate the great work that has been
done on Redis, but I feel it really needs to rethink the whole API layer.

~~~
dvirsky
Most of redis' API is quite coherent. Some of the incoherence is due to the
fact that some commands get less attention, such as LPUSHX (which I've never
really noticed and I've been using redis for 6 years). Some is because of the
core idea of remaining backwards compatible, so even if you have option or
commands added, they will never replace old ones, which can cause a bit of
complexity and inconsistency.

> Why there is even hyperloglog in a database?

Remember that redis is not really a database but a "data structure server". I
have to say I personally don't think this should have been part of the redis
core, and it's a textbook example of what redis modules should be, but it came
2-3 years before modules.

> Where did the need for RPUSHLPOP come from?

It came from distributed work queues, which are a popular use case for redis.
The documentation actually goes into great detail explaining how to use it.

~~~
catwell
LPUSHX got my attention so I opened a pull request making it variadic (along
with other commands) three years ago [1]. Of course since then the codebase
changed and it can no longer be merged.

If there is still interest I could try to fix it, although I don't use Redis
as much anymore and I have not looked at its code for a long time.

[1]
[https://github.com/antirez/redis/pull/1232](https://github.com/antirez/redis/pull/1232)

~~~
antirez
Hey! Yes I'm interested, the PR was not handled for the usual reasons but
making the commands variadic is a good idea. However I'm surprised there is
not just the need to change the command table since I remembered, incorrectly,
all the variants were handled by a single function.

~~~
catwell
Yeah, as you can see the issue was that it is a different function,
pushxGenericCommand(), which is used for LPUSHX, RPUSHX and LINSERT. For me
having the same function for LPUSHX / RPUSHX and LINSERT does not make much
sense (it uses different code depending on whether or not an argument is NULL
anyway) so I had started by making LINSERT not rely on it.

My initial goal at the time was not to make LPUSHX and RPUSHX variadic, since
like you said they are not used so much. It was actually to make LINSERT
variadic, which can result in a significant performance boost compared to
calling it several times.

Anyway, I will try to find the time to adapt it to the current code base.

------
cjcenizal
I love the rise in appreciation for a solid user experience for programmers
these days. I've heard this referred to as DX (Developer Experience).

I have such a feeling of empowerment and productivity when I'm working with
well-designed tools and APIs, with interfaces that fit into my mind the way
the handle of a hammer fits perfectly into my hand.

~~~
komali2
I would say the concept of DX is rising not just in terms of UI, but in the
holistic sense. For example, Windows releasing the Ubuntu Bash and Microsoft
Code in an attempt to make Windows a better DX environment.

~~~
bitwize
Windows had an excellent DX before WSL; Visual Studio in particular is
considered a best-of-breed development tool and ecosystem, years ahead of
anything that's available under Linux. Linux only won in the Web space because
it's easier to deploy at massive scale because no licensing costs. It is _not_
the easiest OS to develop for.

~~~
_nedR
JetBrains IDE seems much more productive than Visual studio while at the same
time being lightweight. So much so, lot of people find it worthwhile paying
300usd per year for Resharper, to get the same tools on Visual studio.

------
quaunaut
Good API design is part of why I try to follow TDD.

I'm not dogmatic about it, but I've noticed that when I do follow it, I
usually have a better understanding of how I'll use my code by the time I'm
done implementing it. Usually because, in the process of testing my code, I'm
getting to 'use' it before I've even written it.

~~~
taeric
This resonates with me. But, I have found that it is often more important to
do several to "throw away" than it is to TDD the first.

That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the
viability of iteration 1 of a program. Instead, it is by iteration 3 that
things have a chance. And, it seems, any process is likely to succeed then.

~~~
crdoconnor
BDD allows you to "think through" the consequences of your user stories and
potentially discard or amend bad stories before they end up getting
implemented and causing problems.

~~~
taeric
Again, this resonates well. However, I have had many cases where I did not
really see what made a story bad until I had almost succeeded in getting it
implemented.

In the end, I always want a way to make iteration 1 work. For it to be the
only time I have to write something. However, experience is having done many
many first iterations.

------
makecheck
The goal is to maximize developers’ investment. Sometimes simplicity is needed
but there are other ways.

For example, _consistency_ : it takes long enough to figure out a new module
without also having to re-learn all of the things you did arbitrarily
differently from the previous module. Pay attention to naming, argument order,
styles of error-handling, etc. and don’t abbreviate things that are not
extremely common abbreviations (e.g. "HTML" is OK; getHypTxMrkpLang() is a
PITA).

Also, if you include lots of examples that obviously work then developers are
more likely to trust what they see. Python "doctest" is brilliant for this,
since you can trivially execute whatever the documentation claims. Don’t
document the ideal world in your API: document what it _actually_ does.

Make your API enforce its own claims in code. Don’t assume that a developer
will have read paragraph 3 where it “clearly says” not to do X; instead,
assert that X is not being done. This is extremely valuable to developers
because then they _can’t_ do what you don’t expect them to do and they won’t
start relying on undefined or untested behavior.

------
dman
I would argue that simplicity and elegance are even more important for mental
models than they are for physical objects.

~~~
bgun
To take that one step further, I would even say that a physical object is
merely a touchable proxy for a mental model. Think of how many things you just
"know" how to use because of elegant or established design patterns. Or how
you move about your own kitchen when preparing a meal.

~~~
JorgeGT
> I would even say that a physical object is merely a touchable proxy for a
> mental model.

This resembles Plato's Theory of Forms:
[https://en.wikipedia.org/wiki/Theory_of_Forms](https://en.wikipedia.org/wiki/Theory_of_Forms)

> These Forms are the essences of various objects: they are that without which
> a thing would not be the kind of thing it is. For example, there are
> countless tables in the world but the Form of tableness is at the core; it
> is the essence of all of them.

------
markbnj
>> The act of iterating again and again to find a simple UI solution is not a
form of perfectionism, it’s not futile narcissism. It is more an exploration
in the design space, that sometimes is huge, made of small variations that
make a big difference, and made of big variations that completely change the
point of view. There are no rules to follow but your sensibility. Yes there
are good practices, but they are not a good compass when the sea to navigate
is the one of the design _space_.

Love this paragraph. That's why it's art.

------
EdHominem
This isn't wrong, but the problem in general is that non-programmers have pre-
decided that "simple UI" means a clickable GUI, probably with a Paperclip type
assistant.

The benefit of the GUI is to present something that text can't - such as lines
between components, or pictures, etc. But what's the (specific) domain use for
those thing? If there isn't one then a GUI is just a text UI with a mouse
pointer and a bunch of overhead.

There's almost zero connection between what seems simple to your boss in a
screenshot and a productive tool. If someone really removed unneeded
complexity from a burdened UI, then great, but one person's bell and whistle
is another's required tool.

~~~
humanrebar
Agreed. I've seen many simple, bulletproof UIs and APIs that only support a
discrete set of workflows, so they ultimately fail as expert tools.

Sometimes you don't want an expert tool, you want an easy button. That's fine.
But often there's an inherent tension between 'can never fail' and 'lets you
open up the throttle and tear through your problem'.

Compare the editing and reviewing workflows supported by a share drive and
those supported by git. A shared folder is undoubtedly simpler, but good luck
maintaining a coherent revision history or editing a document in parallel on
different isolated subnets.

------
ChrisArgyle
The central thesis here is that APIs should be treated like GUIs. Make them as
intuitive as possible to minimize brain space waste (ie. memorization of non-
transferable, vendor-specific knowledge)

Sadly, the post is too short to discuss what "intuitive" means for an API
(which could probably fill several volumes).

~~~
ArkyBeagle
I've built GUIs that completely contravened every possible thing I've ever
seen written about GUIs. For example, _one ugly button_. No "exit" button even
- you can hit the X in the corner for that.

Behind that button, there was no possible way to make a mistake. Now, to be
fair when a constraint was violated ( which only happened when something
physically broke or somebody didn't set a physical thing up right ) there was
a comprehensive explanation of the failure - "The U42 wire for the Gerfish
Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2
of the service manual." That happened in a popup.

To me, that's a good GUI - "just tell me when to go to it." But there is an
ostensible public choice theory problem with this approach - who will be paid
for training in it? Where will a support network for it exist? Nobody, and
nowhere. Show this to people, and you can see it on their face - "there goes
my job." They think this even after I show 'em the popup.

It's _asocial_ and that's more important that "it's correct." But it worked to
sabotage any expectations people might have about me writing GUIs.

Also, when people tell me that corporations are cost driven these days, I just
laugh because of this.

------
soneca
When people say we need to teach everyone how to code, I agree. But first we
need tools that allow (any) people to code with different levels of knowledge
and experience.

Like math: you learn basic Math. Then you have a calculator for basic
operations. Then you have MS Excel for general professional use. Then you have
MatLab/R and stuff for specific use.

For programming I have the impression that you learn to code and then you,
from start, have to learn how to use the most sophisticaded tools in place.
And several of them.

~~~
blakeyrat
> For programming I have the impression that you learn to code and then you,
> from start, have to learn how to use the most sophisticaded tools in place.
> And several of them.

Right; and if someone makes a tool which is (attempts to be) more friendly to
use, it's constantly derided by "real" programmers. Look at, for example,
Access, Visual Basic, PHP to some extent.

The correct answer to, "people are using Access to write software" shouldn't
be:

"that is garbage! They need a real DBMS! With multi-user support!"

It should be:

"well, Access is clearly showing us that there's a huge under served market of
people here, let's figure out what it's doing that appeals to them then work
on an improved version."

~~~
dTal
While I agree, it bears mentioning that sometimes the thing that appeals is
popularity itself, or good marketing, or "written by Microsoft". It would be a
wonderful world if people always chose solutions on technical merits, and the
best solution always won, but I don't think we live in that world.

~~~
penguat
or "It's what I have on my office computer and I don't get admin rights"

------
bastijn
Sorry, couldn't bring it up to read the article. It was rendered on my screen
in what looks like a "programmer" font on a page that looks to be made for
"programmers". It is basically plain white with a wall of black text in a font
that strains my eyes. Or at least at my phone.

Programmers are not different, they need equally readable websites.

P.s. ;) or ;(

P.s.2. In before the "HN is also xyz". HN might not have fancy styling but it
did carefully consider readability.

~~~
seanmcdirmid
This is the first thing I noticed also. Maybe the use of a fixed-width was
meant to be ironic since the author is comparing against UX design?

~~~
bastijn
I'm afraid not :(. Also, fixed-width is not the only issue. The chosen font
type and spacings look real programmy but are not pleasant to read.

------
Bjartr
In my opinion, a poor developer experience is the primary reason GWT never got
more traction than it did.

It's quite the technical accomplishment, but it's challenging to use in ways
that have no reason to be challenging from an experience perspective.

------
Godel_unicode
It's frustrating for me that people seem to be trying to force everyone into
the same UI patterns, regardless of the target audience's skill level and
difficulty of problem. Novice users need different UI's than do advanced
users, ditto people solving easy problems vs hard problems.

Michael Schumacher and your 15yr old new driver need very different UI's. The
new driver needs a simple UI and lots of protection from making mistakes to
solve the easier problem of getting from A to B without crashing. Mr
Schumacher on the other hand needs a complicated UI and 0 hesitation in the
implementation of his decisions to solve the much harder problem of breaking
the world record at Monaco.

Determine who your audience is, and how hard the task they're attempting is,
then implement the appropriate UI. Defenestrate anyone who tells you simple or
complex, GUI or CLI is "inherently better" without considering the problem.

Is red-eye reduction in MS Paint or Python PIL better than in Photoshop?
Conversely, would you rather use visual studio or notepad to write a 2-line
script?

~~~
unabst
> Michael Schumacher and your 15yr old new driver need very different UI's

The UI isn't different because the users are different. The cars are. An F1
car is crammed for a reason. This is a deeper problem than adjusting for
users. And this is what most still don't get.

This UI vs functionality dichotomy does not exist. Any compromise is
artificial. UI must be purely functional, and from function emerges pure form.
A good designer is focused just as much on function, as is a good developer on
design. In other words, they are the same person. And this is basically
Apple's design philosophy in a nutshell.

A UI designer didn't design the cockpit of the F1 car, nor the Camry. They may
have chosen the font, the shapes, the icons... but everything was already
there. Function necessitates it. And the interfaces of both cars are
incredibly simple.

~~~
Godel_unicode
Most still don't get it because it's not true. Look at all of the additional
options with non-obvious discovery that Apple has added to the iPhone because
some more advanced users want e.g. swipe up quick settings. If you as a user
want more control, the design needs to include more controls. Open up MS Paint
on one monitor and Photoshop on the other to see what I'm talking about. I
realize that this concept is offensive to designers, but designer happiness
isn't the goal. Good UI is the goal.

The UI's are different because Schumacher wants more precise control (brake-
bias, suspension rate, turbo angle of attack, etc) and you can't get that
level of control without a more complicated UI (you need the appropriate
buttons and levers for all of those things).

The title of the person who lays out the Ferrari F1 car's cockpit is literally
UI designer. If you think an F1 car's cockpit is simple then you should
reconsider. The cognitive load of those two sets of controls is very
different, made possible and desirable because one set of users is expert and
the other isn't.

~~~
unabst
No. The UI designer does not choose functionality on their own. They need
intimate knowledge of how the car and driver work together, and then must
simplify to the bare necessities. The better they are at the job, the better
they know about both. And same applies to the developer and even the driver.
The best drivers are deeply involved with every aspect of their cars. And in
the end, nothing is redundant.

And no, MS Paint and Photoshop are not the same program with one just having
more options. Photoshop is a beast, and it's UI has improved over the years --
to match that functionality.

The UI is different because Schumacher is driving an F1 car.

> additional options with non-obvious discovery

This is bad design. iTunes and Apple Music are horrible also. Not everyone at
Apple gets it. But everything that made Apple successful was about getting it.
Steve Jobs got it.

> designer happiness

There is only designer happiness among those who don't get it. There is no
designer-developer distinction to the user. Ultimately all there is is user
happiness.

------
mapleoin
I feel one of the worst API tooling right now are the ones that come with AWS.
Everything from the AWS Console's UX and accessibility to Dynamo's APIs are
just a nightmare to understand and deal with day to day.

~~~
madelinecameron
I don't understand why AWS' free-tier requires putting things into a VPC.

It is a complete turn-off. It took me _days_ to figure how to configure it
correctly to access it through SSH without following a guide that builds out
some giant infrastructure.

It should just be one-click to throw everything up that I need and hide all of
that extra config behind a wall that I can access if I want / need to.

------
Animats
Much of the trouble with IDEs revolves around not coding, but finding all the
parts. The usual IDE Does Not Play Well with Others. Most IDEs have some
strong ideas built in about where Things are Supposed to Be. This causes
trouble when they have to interoperate with some other system which also has
strong ideas about where Things are Supposed to Be. (Makefiles, Cargo, Github,
Go's tools, packaging tools, etc.)

Working around this involves either manually editing text files or trying to
find the right dialog box into which to put some pathname.

The other big problem with IDEs is that they usually have no understanding of
the tools they invoke. This is a UNIXism - programs take in parameters, but
just return an error code. There's usually no machine-processable output from
compilers or linkers. If you're lucky, the IDE might be able to associate an
error message with the right source line in the right file.

------
rectang
There is tension between the benefit of designing user-friendly APIs and the
temptation to overspend on effort to design great APIs. It is sometimes hard
to anticipate how often an API will be used.

~~~
forgotpwtomain
> There is tension between the benefit of designing user-friendly APIs and the
> temptation to overspend on effort to design great APIs. It is sometimes hard
> to anticipate how often an API will be used.

I think in antirez's case there is little 'underestimation' :)

Returning to the more general practice - I agree, it's easy to spend several
days building a nice abstraction for something that is not extended again, or
something that is extended in a way different from what was anticipated and
the abstraction doesn't help. From my experience what has worked the best in
terms of internal structure, is to write a basic and working version (this is
when you don't know that there are any other users) and to refactor it into a
nice abstraction when you reach the point that it needs to be extended - also
a huge positive is once it needs to be extended, you know what the abstraction
is going to be used _for_.

~~~
davidjnelson
I think that's really smart. That's what I do too. When you do the YAGNI way
and start seeing it over and over refactor it to an abstraction. Challenging
in the agile world though. Businesses don't want to pay for refactoring.

------
gaddr
>Learning to configure Sendmail via M4 macros, or struggling with an Apache
virtual host setup is not real knowledge. If such a system one day is no
longer in use, what remains in your hands, or better, in your neurons?
Nothing. This is ad-hoc knowledge. It is like junk food: empty calories
without micronutrients.

I agree with this. Too much time is spent in learning how to work with poorly
designed interfaces. This sort of knowledge of man made, arbitrarily designed
tools doesn't really teach us anything that applies outside the highly
specific use case. And it will likely be obsolete within a couple few years.
The half life of IT knowledge is short.

While complex tools might be unavoidable, we need better ways to interface
with them. And better documentation. People rely on SO and the like to
understand how to interface with an API, decode cryptic error messages or
configure some tool because the documentation and interfaces are often
lacking.

------
lallysingh
UI's a funny term for APIs. I don't think it's that complex.

APIs are written documents describing external controls to a system's
behavior. A good document can describe both the controls and behavior clearly
and succinctly. A bad one can describe the same in long and convoluted
language that effectively hides the underlying system. Often in a mess of
"should" and "can" clauses, with lots of passive voice, vague assumptions, and
unnecessary complexity and verbiage.

For some reason, I feel many programmers write documentation the same way that
they wrote their X-page essays for English class. They're just trained to
write fluffed-up junk that fills some imaginary requirements of a long-
irrelevant class.

EDIT: To clarify: I'm describing the actual types and methods themselves. They
infer an underlying mechanism and a means to control it.

~~~
GavinMcG
An API isn't the document - it's the interface. (That's what the "I" stands
for!) One which developers use, which would make it a type of UI even though
it's not necessarily the UI that's exposed to end users. And that's kind of
the point: the documentation should certainly be clear and well written, but
the necessity of all that can be minimized by carefully designing the way
developers can work with your tool in the first place.

~~~
lallysingh
Every identifier in the system is a bit of documentation. I submit that
there's a difference when you name a function:

bool ufklsjblsboabfds(int, int)

and

bool operator<(int, int)

I know that to many, the idea of individual identifiers being documentation is
a bit radical, but I think it's the first documentation a developer sees. It's
the documentation built into the body of every piece of code that they read
and write.

~~~
GavinMcG
> I know that to many, the idea of individual identifiers being documentation
> is a bit radical

I think the opposite – it's totally mundane to most people. Aside from the
intellectual exercise it requires, people don't have any reason to use a
language that used bool ufklsjblsboabfds(int, int) any more than they would
use Brainfuck.

So, sure, the API "documents" the functionality in the most minimal way
possible. But when you say "documentation" you're using a term that almost no
one will understand in the way you mean it.

------
webartisan
It's surprising that so many good tools are regretted because of lack of clear
documentation and intuitive API (looking at you, Webpack).

No, a good user experience is not a luxury you can afford to omit. Stop
creating backlog tickets to "simplify code". It's just plain selfishness.

------
Zigurd
Nowhere other than in programmers' tools would it be considered an acceptable
UI architecture to layer a GUI (usually a turgid dialog box) over a CLI.
Moreover the dialog gives no indication whether the inputs are correct or
consistent with one another until an unhelpful error is displayed. The
components of a toolchain need real APIs and real libraries implementing those
APIs, designed for the kind of object-action manipulation that makes desktop
productivity software productive: You can't apply the wrong action to the
wrong object. The UI simply won't let you.

------
zamalek
Never allow a user to do the wrong thing on your GUI - they must be guided
toward the "pit of success."

The same thing can be said for an API. I've be pair architecting/coding a
pretty substantial spike over the past two weeks with some hairy revision
control and dependency management stories. The main thing we've been aiming
for is making extremely sure that developers don't drop a dependency into our
DAG. The solution was obvious, but the API design has _outright_ dominated
those two weeks.

------
metalliqaz
Lets take Firefox as an example. Over the years they have been simplifying the
interface, especially once Chrome came into the picture. Every time they
remove something I find myself annoyed that a function I used, which was in an
intuitive location, is now hidden away in a deep sub-dialog. That is, if it
even survived at all.

I'll keep my complex UI thank you very much. Complex doesn't have to mean
complicated.

~~~
makecheck
Removing something is almost forgivable if it survives as a low-level
configuration option.

Yet Firefox has changed behaviors that I _can’t_ fix anymore, such as always
remembering everything in a Downloads list (they outright removed any way to
prevent this so one has to manually clear it).

------
jweir
I want simplicity and _longevity_.

A simple interface that is changing or obsolete is still useless knowledge I
have learned.

Longevity is another reason a developer(s) should spend extra time getting
their design polished. Get it right so the product can grow and does not need
to introduce many breaking changes.

Make upgrades a joy, not a PITA.

------
olavgg
An example I currently have, Statistics Norway recently released version 2 of
their API. You can now download about every data source they have. However
they prefer that developers use JSON-Stat([https://json-
stat.org/](https://json-stat.org/)) instead of CVS's. Luckily they do support
CSV, but it is messy with inconsistent layout. I still prefer it over JSON-
Stat though, as I feel JSON-Stat is way too complicated for serious use. That
is also probably why there are so few JSON-Stat clients.

CSV's are simple to parse! JSON, XML are more complex beasts to parse, they
are especially hard to parse when they don't fit in memory. I do use a lot
JSON, dont get me wrong, but it's mostly for small data sizes.

Do anyone else here feel the same about JSON-Stat?

~~~
alblue
Anyone who claims that CSVs are easy to parse have obviously never had to deal
with the kind of junk that you see in real CSV files. Quite apart from quotes
(is a "a,b" two fields with '"a' and 'b"' or a single field with three
characters?) there are also things like new lines like

like,"this newline"

Which are part of the field and not two records. Or having to deal with user
names like Blue, Al (outlook's preferred format for representing people's
names).

Or you end up with O'Reilly - is the ' part of a quoted string or not?

And of course a comma isn't necessarily the only separator - what about tabs?
Or a document where an intermediary has saved it in an editor that has
"helpfully" converted tabs to N spaces (where N is a universally disagreed
upon nonzero positive integer)

~~~
olavgg
You're absolutely right, but this is still a problem with JSON and XML. I have
seen dates being represented in all kind of formats in the same document. Data
cleansing has always been important when working with data in any format.

~~~
reverius42
The difference is that JSON and XML can be described by a grammar and parsed
by any standards-conforming parser. Good luck doing that with CSV.

------
specialist
Good interfaces are hard. Bad interfaces add chafe, cognitive load, friction,
frustration, are hard to document, etc.

Speaking of which, I'd prefer cut & paste friendly this:

$ redis-cli hostname:port

To slays me every time this:

$ redis-cli -h hostname -p port

------
awt
Naggum on UIs:

"this is my _workbench_, dammit, it's not a pretty box to impress people with
graphics and sounds. when I work at this system up to 12 hours a day, I'm
profoundly uninterested in what user interface a novice user would prefer."

Full post:
[http://www.xach.com/naggum/articles/3065048088243385@naggum....](http://www.xach.com/naggum/articles/3065048088243385@naggum.no.html)

~~~
jasonlotito
A simple UI is not necessarily one a novice would prefer.

------
aldanor
I agree with the author, and I think the idea is somewhat applicable to
everyday tools like text editors. This is partially why I've switched to Emacs
(Spacemacs/evil) after using "conventional" text editors like Sublime Text for
ages. Although GUI of ST3 may feel nicer at times, the UI (in a more general
sense of this term) of Emacs is far more logical and is definitely a lot of
fun to use.

------
seanmcdirmid
Programmers can also benefit from the readability of proportional fonts. I
like this article, but it is hard to read for reasons beyond the writing
itself.

------
transitorykris
It's amazing that Docker has not been cited in the comments so far. LXC,
jails, zones, etc were around for some time. What changed things imo was the
incredible simplicity of the Dockerfile and the tooling around it. Re-watch
the first public demo:
[https://www.youtube.com/watch?v=wW9CAH9nSLs](https://www.youtube.com/watch?v=wW9CAH9nSLs)

~~~
pathsjs
I find docker increasingly complex and frustrating, at least for the pretty
common use case of isolating dependencies for development. See vagga for an
example of simplicity. There you have no daemon, no file permission conflicts,
a simple way to run commands in containers and more

------
dewiz
...and some people drive complexity by design: be complex to be consistent
(resistance is futile). I've seen that in big orgs where managers like
"achieving" consistency (yay), even if developers are wasting time and money
to adapt to cumbersome systems. Sometimes I see the same in communities, hype
can promote a bad solution, while the lack of advocates (and time) can kill a
better one.

------
ori_b
It's not just simple UIs, though -- As a programmer, I generally need to be
able to dig down through the code and figure out what's going on behind the
scenes.

This means that the implementation is often just as much the UI as any other
aspect of the program. Simple implementations are just as important as simple
UIs.

~~~
davidjnelson
That's why redux is really nice - it's ~100 lines of code at its core.

------
tobyjsullivan
The other benefit of simplicity - on top of the wasted time and learning - is
reducing the opportunity for mistakes.

Misunderstanding of what's happening (or more commonly what is not happening)
with some API endpoint due to an overly complex - often over-abstracted -
design can be a very expensive mistake.

------
imakesoft
This article reminds me as a designer how Hacker News (and Reddit) could use a
face lift. I have a hard time reading the small text and identify in the
listings that what's a link and what's not. :/

------
ben11kehoe
Yes, all programmers are the same; none of them have different needs or
desires.

~~~
Tenhundfeld
To me, it's clear the author means, "Programmers are not different [from other
types of computer users]; they need simple UI's [too]."

You seem to be interpreting it as, "Programmers are not different [from each
other]; they need simple UI's [that limit their expressiveness]."

I guess? Honestly, I'm not really sure where your comment's coming from.
Please elaborate.

------
lolive
I would _love_ a UI for my httpd.conf :)

Trillions of checkboxes with cryptic names and gigantic tooltips to dispay the
detailled documentation (plus the zillions of relevant StackOverflows for the
real-life bugs).

Nope, that's just sarcasm. Sometimes the best UI is a conf file, a web browser
and Google.

~~~
kylemathews
What you're describing is a _GUI_ or Graphic UI. A conf file is a UI. As is a
library or service API which is what he's discussing.

