4 ms·

A good catalog of mostly skills issues. Many of the points raised point to real glitches, cruft, and frustrations with using the CLI. Those get more frustratin

A good catalog of mostly skills issues. Many of the points raised point to real glitches, cruft, and frustrations with using the CLI. Those get more frustrating for people who only occasionally use the CLI, and less so for those of us who live in the shell. Many of the same kinds of problems exist in GUIs. I rarely use Windows so when I do I can’t find or discover what I need. Over time you remember the commands and flags, write aliases, set up config files, and mostly it becomes second nature.

eviks 2y ago
You also forget commands and flags over time, leading to the responses you denigrated as a skill issue. And this is not from a "rarely use" crowd like in your Windows example
- gregjor 2y ago
  Sure. That's why --help and man and info exist, along with the volumes of online and printed documentation. The Unix/Linux shell and command line tools have to rank near the top of most-documented software in use. When I wrote "skills issue" I had in mind the mentality that equates learning the standard tools, mastering the environment, and always improving skills with a waste of time, a few minutes or hours diverted from pasting together API calls or prompting an LLM. I have watched programmers spend hours setting up color schemes and fonts in their IDE, and then complain that they can't remember a flag for grep. Years ago I worked at a software company where everyone used the Eclipse IDE. I tried it but it felt too slow and buggy, so I fell back to my usual vim in the terminal. Every week or so the team came to a halt when Eclipse got an update to the Subversion SCM plugin (this happened before git took over). Eclipse would have a version of Subversion incompatible with the version on the servers, causing the team to stop to deal with that. I used svn from the command line, same version as the server, so I could keep working. Eclipse broke down so often I couldn't understand the team-wide devotion to it. And they made fun of my "arcane" and obsolete workflow. Now I work with teams who use VSCode and I see the same kind of thing play out -- plugin updates that break the whole environment, weird problems from the bowels of npm that no one can figure out. And they tell me they don't have time to learn vim.
Analemma_ 2y ago
This comment is a good distillation of my frustration with Unix ideologues. Unix and the CLI can never fail, they can only be failed; any possible unhappiness is a "skill issue"; it's your job to memorize a thousand arcane and badly-systematized program names and flags, created in an era of RAM and disk space limitations which have no relevance today, etc. And going "many of the same problems exist in GUIs" is a "no u" tier of response.
- skydhash 2y ago
  Do you expect to go inside a plane and fly it with no training? Or pick up a violin and play a sonata? The terminal have its flaws, but all other interactions models have their own. But when people don't try to learn the basic tenet and just ask why it can't be like $other_system_they've_learned_first, you bet that they're going to point you to the manual.
  - fragmede 2y ago
    I expect that pilots are allowed to have opinions about systems in the plane as being user unfriendly, like MCAS of 737 Max fame. I expect violinists to be allowed to complain when their bow is rosined wrong. Sure, we should expect users to at least read parts of the manual, but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation, haven't you got to ask to yourself that there's a chance we're making this unnecessary hard on ourselves for no reason?
    - skydhash 2y ago
      > but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation That was an unnecessary spend then. You should ask yourself why ffmpeg still exists if if it's that hard to use. There's a plethora of simpler tools that exists for simple uses (handbrake, XLD,...). The truth is that if you want versality, there's no better than ffmpeg and it's core usage is relatively simple. It's an input | filter | output pipeline, with various options to fine tune each one. If you don't have the domain knowledge, it will be hard, just like a layman inside a plane cockpit. But if you do, everything makes sense. Same with a lot of other software. There are bad design out there, but if something persists with no other incentive than its users, you should probably ask why first.
follower 2y ago
> 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 2y ago
  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 2y ago
    > 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?
spudlyo 2y ago
> A good catalog of mostly skills issues. It's a good reminder to some of us that we are not in fact imposters.

eviks 2y ago

You also forget commands and flags over time, leading to the responses you denigrated as a skill issue. And this is not from a "rarely use" crowd like in your Windows example

gregjor 2y ago
Sure. That's why --help and man and info exist, along with the volumes of online and printed documentation. The Unix/Linux shell and command line tools have to rank near the top of most-documented software in use. When I wrote "skills issue" I had in mind the mentality that equates learning the standard tools, mastering the environment, and always improving skills with a waste of time, a few minutes or hours diverted from pasting together API calls or prompting an LLM. I have watched programmers spend hours setting up color schemes and fonts in their IDE, and then complain that they can't remember a flag for grep. Years ago I worked at a software company where everyone used the Eclipse IDE. I tried it but it felt too slow and buggy, so I fell back to my usual vim in the terminal. Every week or so the team came to a halt when Eclipse got an update to the Subversion SCM plugin (this happened before git took over). Eclipse would have a version of Subversion incompatible with the version on the servers, causing the team to stop to deal with that. I used svn from the command line, same version as the server, so I could keep working. Eclipse broke down so often I couldn't understand the team-wide devotion to it. And they made fun of my "arcane" and obsolete workflow. Now I work with teams who use VSCode and I see the same kind of thing play out -- plugin updates that break the whole environment, weird problems from the bowels of npm that no one can figure out. And they tell me they don't have time to learn vim.

Analemma_ 2y ago

This comment is a good distillation of my frustration with Unix ideologues. Unix and the CLI can never fail, they can only be failed; any possible unhappiness is a "skill issue"; it's your job to memorize a thousand arcane and badly-systematized program names and flags, created in an era of RAM and disk space limitations which have no relevance today, etc. And going "many of the same problems exist in GUIs" is a "no u" tier of response.

skydhash 2y ago
Do you expect to go inside a plane and fly it with no training? Or pick up a violin and play a sonata? The terminal have its flaws, but all other interactions models have their own. But when people don't try to learn the basic tenet and just ask why it can't be like $other_system_they've_learned_first, you bet that they're going to point you to the manual.
- fragmede 2y ago
  I expect that pilots are allowed to have opinions about systems in the plane as being user unfriendly, like MCAS of 737 Max fame. I expect violinists to be allowed to complain when their bow is rosined wrong. Sure, we should expect users to at least read parts of the manual, but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation, haven't you got to ask to yourself that there's a chance we're making this unnecessary hard on ourselves for no reason?
  - skydhash 2y ago
    > but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation That was an unnecessary spend then. You should ask yourself why ffmpeg still exists if if it's that hard to use. There's a plethora of simpler tools that exists for simple uses (handbrake, XLD,...). The truth is that if you want versality, there's no better than ffmpeg and it's core usage is relatively simple. It's an input | filter | output pipeline, with various options to fine tune each one. If you don't have the domain knowledge, it will be hard, just like a layman inside a plane cockpit. But if you do, everything makes sense. Same with a lot of other software. There are bad design out there, but if something persists with no other incentive than its users, you should probably ask why first.

follower 2y ago

> 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 2y ago
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 2y ago
  > 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?

spudlyo 2y ago

> A good catalog of mostly skills issues. It's a good reminder to some of us that we are not in fact imposters.