Speak English to me: The secret world of programmers

> Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures.

The useful part of the menu is the text! Especially if I'm somewhere with novel or unfamiliar food, there's no way I can guess what actually went into a cooked dish or what its texture is like by looking at pictures of it. But all of that I can infer from a reasonable description of the dish given in terms of its ingredients and how it is cooked.

But if the waiter asks 'what do you want', that is indeed an offer for them to search on my behalf much more efficiently than I could do visually through a menu! I'm free to say 'something savory and salty' and see what they offer me, or ask 'what chicken dishes do you have?', or 'I need something light, because I'm not very hungry'.

Even in the example you chose, visually scanning a menu is less efficient and more restrictive!

> how it feels for new users to be presented with "> _".

Of course a shell prompt is not self-explanatory, because you have to learn the commands for asking about other commands.

But there's also no reason that accessing the command line for the very first time has to mean being dropped at a blank prompt with no instructions. That's completely inessential to the paradigm, and it's unfortunate that this is such a common default.

> Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Sure it is. I do this with commands I've never used or use very rarely all the time. In the worst case you try a few synonyms and words for related concepts and find what you're looking that way.

You're also not making a 1:1 comparison here. One may need some basic instruction on the command line environment itself, e.g., how to search for and open documentation at the command line. But that is not part of the process of learning to use a new command line application. You're comparing the cost of learning a single application to the cost of learning an entire paradigm and environment.

> But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

What volume of research has ever even investigated command line usability and how it can be improved? Where has that research been applied? How much of it focuses on applications/domains which are comparable in complexity to an absolute behemoth like Excel?

Consider the part of this discussion that has focused on developers who are hesitant to use the command line. Is there seriously any reason that a text-driven environment navigated non-spatially, through search/filtering, should be any harder to use than an IDE, like those same developers use every day?

----

I also wanna be clear that I'm not saying that Excel's non-obviousness is a fatal flaw, or that people who are effective with it should switch to something else. Excel is actually an impressive, capable piece of software.

I'm also not saying that most command line environments as they exist do a good job of being easy to jump into. They generally don't! I think the command line has long been largely neglected in terms of UX, and it shows.

But the way CLI environments lend themselves to searching, filtering, composition, and reusing old actions but slightly modifying them also make searching for, picking up, and using new command line programs really smooth and fast in a way that I think most of us don't give enough credit.

Double tap the home button and it brings up the app selection screen. Took me an embarrassingly long time to figure that out some years back.

"man man" explains the section numbers.

The one thing I wish people would get over is their fear of the terminal. This isn't to suggest that they should use it, never mind embrace it, but they should not have an adverse reaction when someone gives them specific insructions to type in a command then copy+paste the results while providing technical support. Such insructions tend to be much more accurate than sending people on a GUI scavenger hunt, particularly when you consider that GUIs tend to vary in time.

Alas, as the article states, it is as though you are speaking a different and very intimidating language to non-technical users so the end result is nowhere near as positive as it should be.

For a loose definition of "programmers", sure they do. Maybe it's a sysadmin, maybe it's a teen who writes/ builds game mods, but IME most normal folks have someone at work or someone in their family they can ask/ harass, and they'll do this before they'll start typing error messages into a web search.

Folks will come and ask for help but then you have to tease out of them what the problem was. The entire idea of "I got this error; I will look up this error" is _foreign_ to most normal folks. It is grand when they came with an error message in hand.

But even when someone has an error message, they often turn their brain off: I worked with a developer who would send screenshots of a text error rather than just copy and paste it, which would force one of us to retype what he wrote into a web search.