[follower]

> A good catalog of mostly skills issues.

Seems a bit harsh to call out the developers of all that software like that.

But I do agree that software interface design and empathy are both skills that many software developers might benefit from developing further.

In their defence, developers unfortunately often don't seem to have access to many resources for upskilling themselves in these areas either--people don't seem to realise that simply telling someone to, say, just "git gud" at empathy is actually a form of gate-keeping that doesn't really benefit anyone.

Admittedly, if I was feeling snarky I might be tempted to say being able to create software interfaces that may take a person from four to twenty-one or more years[0] to learn could be considered a "skill" of sorts, I guess, but that wouldn't be very empathetic of me.

----

[0] "40% of people answering this survey have been using the terminal for 21+ years / 95% of people answering the survey have been using the terminal for at least 4 years"

[gregjor]

I meant that people who struggle to use basic CLI tools have a skills issue. The tools date from decades ago, got embedded in millions of scripts and workflows, and so their UI won't change. Like it or not we have to accept those tools have become part of the background, so complaining about grep or awk or bash just goes nowhere.

The people who wrote the shells and tools like vi(m) and awk didn't suffer from skills issues or lack of empathy. They wrote tools for themselves and other skilled programmers, in environments that no one under 50 can remember or imagine. Monochrome 80x24 displays, 8 MB of RAM, floppy disks (or worse) -- major hardware and software constraints. Blaming them for not anticipating modern hardware and software (and attention spans) seems like blaming Henry Ford for not inventing the electric Mustang.

[follower]

> I meant that people who struggle to use basic CLI tools have a skills issue.

I very much understood that's what you meant.

(And assumed you meant "skills issue" in the dismissive sense--if you didn't, ummm, feel free to skip to the last line of this comment, I guess...)

My comment was written in a manner to "humorously" imply I misinterpreted your comment as criticising presumably much older individuals rather than the actual intended targets of the criticism. This was in an attempt to prompt a possible reconsideration of the statement.

Seeing as I obviously failed in my attempt, let me restate my point less delicately but more clearly:

Unlike the tools from decades ago that can be & often are useful today--in spite of their less than perfect interfaces; attitudes that lead to shallow criticisms of people's skills are outdated, should be deprecated & removed from use--because such gate-keeping serves no useful purpose. In fact, it never did.

----

I mention this because I happen to care about our shared hobby/industry and those who have chosen to be part of it--because the technology is really fucking fun and/or fulfilling and/or frustrating.

And if the technology can be really fun why wouldn't I want as many people who are interested in it to have some of that fun? Or, heck, earn a living with making it less frustrating?

Humans are often already fantastic at self-critique of their skills--they don't need other people to shit on their skills too. (And I'm intentionally writing all this in case some of those humans are "in the room with us now".)

----

Besides, these survey respondents were primarily people who have stuck it out with our imperfect technologies for at least four to twenty or more years.

Not only were they prepared to admit that they didn't know something (something I personally find challenging to do, at times *cough*) they were kind enough to do so in the context of a survey that would help Julia Evans create an effective targeted resource to help people learn the very skills that are apparently of such importance!

----

I would also note, for example, one might consider it reasonable if only ~7-10% of people might know to use `cmd1 |& cmd2` for redirection of both stdout & stderr given it has apparently only existed since Bash v5.0, a mere six short years ago--and, coincidentally, probably one of my favourite Bash tips I've learned in the past five years because I could never seem to remember which order the `2>&1` went in--and seems maybe I wasn't the only one?

Why, if I was feeling petty, I might even point out that the existence of `|&` might even suggest that decades-old tools can in fact change their UI and that even complaining about bash might not just go nowhere.

Why, if I was feeling optimistic, I might even imagine that maybe attitudes can change!

----

On a definitely related & probably incredibly condescending sounding note:

What's a useful CLI tool tip you'd suggest would be valuable for people to know?

[gregjor]

You can read skills issue as an insult or call it gatekeeping. I meant it literally: not learning common and fundamental skills of the craft of programming. Worse, dismissing tools as arcane or poorly-designed rather than learning how to use them. And blaming laziness or poor memory on the tools.

People actually frequently fail to self-critique their skills, leading to what we call the Dunning-Kruger Effect, the Expert Beginner, the 21-year-old "senior engineer." Listening to and learning from someone who has mastered a skill -- a mentor -- describes one of the best ways to learn something. Interpreting criticism as a personal insult, then blaming inanimate things like Unix CLI tools, doesn't seem productive or professional.

Calling command line tools poorly-designed, arcane, cryptic, etc. blames the tool, and perhaps by extension the author. I have managed to remember 0=stdin, 1=stdout, 2=stderr for decades, and I expect anyone who wants to get into programming can remember three file descriptors. If they can't remember those things, or look them up when necessary, and then blame the operating system or tool, what would you call that if not a skills issue?

As for the survey results that started this thread, I interpret them in the context of my own (40+ years) experience programming. Some people master the Unix CLI well enough to get things done with it. They appreciate the original intent of composability, "everything a file," plain text as the common format. Many other people have learned to type a few commands they don't understand, or copy and paste one-liners found online. Those people "use" the command line in the same sense that I "use" TurboTax -- infrequently and without motivation to master it. I have and continue to work with programmers who have a terminal window open all the time in their IDE, but can't actually do much with it. Then they get on threads like this to complain that command line flags "lack discoverability," as if the man tool didn't exist.

You can criticize what you perceive as my attitude. I have mentored and taught enough programmers how to improve their command line skills over the years to feel OK with myself when I tell complainers to stop blaming the tools. I got lucky early on and had mentors who taught me this stuff, the concepts and design behind Unix and its tools, and got me through my skills issues. Now when I run into something I don't understand I interpret it as my own skills issue, not as a sign that another programmer didn't know how to predict the future or didn't care about correct "design," as if that described anything real.