Programming

I knew basic CLI commands (such as cd and ls) for a while, but did not do learn much more. Some things have helped me grow my skills:

• Necessity: Some times I need to do something on a VM or container that does not have a graphical interface installed. Some utilities only have a command line interface and not a graphical client. My only option is to Google how to do it. The more I do it, the less I have to Google and the more focused my searches become (instead of searching for "How to do x", I search for "How to do x in utility").
• Learning from others: For many tasks, I follow internal or external guides, which typically use CLI commands. Often I look at how my coworkers accomplish tasks and pay attention to what commands they use. Then, when I have time, I look up any new commands I saw and decide if they will be useful for me too. Lately, I have been doing code reviews that involve shell scripts. Those are especially nice, because I can take my time, going line by line, and understand what each command does.
• Keep notes: Every time I find a command that I think I will need again, I copy it into a text file (and I have many such text files). It also makes it easier when I need to run the command with slightly different arguments (a different commit id or something), I can just edit the command in my editor (with searching and undo) and paste it in to my terminal with all the flags and arguments correct.

What did it for me is I stubbornly refused to use Git via VSCode and stuck with the terminal. I also stubbornly refused to change my default text editor for GIT to something other than VIM. One light bulb moment I had, funnily enough, was when I finally read the VIM docs and learned how to save and close rather than panicking when it popped up (this was early on.... but not THAT early on ... so still funny). That sparked my curiosity to truly learn VIM.

After that, I realized command line tools could be learned and advantageous and so it just went up from there.

Honestly, I've noticed a difference in the confidence level of peers using command line tools based on whether or not they learned GIT using command line or jumped straight to just clicking the buttons in VSCode.

Do everything on your command line.

Why click and drag files when you can mv *.png

Why use an IDE when you can setup vim (or space vim on neo vim) to load all the plugins your IDE would need, but only for the particular tasks that would leverage all those plugins (saving you overhead when you're not leveraging those plugins)

Why use word when you can use pdflatex to turn your .tex files into .PDFs, with vim setup to trigger pdflatex on every post buffer write event, while zathura renders the PDF automatically

Why manually start your code, when you can set it up to trigger automatically at start up or in response to other events

The answer, of course, is because it's effort. The pay off is getting marginally better on a skill curve with an infinite ceiling. But the point being, anything your computer does, can be interacted with functions and variables / data structures, and can be automated with shell languages

If their comfort level is limited due to lack of experience, I tend to sandbox them somehow and then walk them through a couple examples of “danger” vs “ok, this definitely won’t be irreversibel if it’s wrong, but I think it will do what I want.”

A couple of my go tos are the obvious rm -rf / vs ./ and a sed with and without -i on some random text file.

That naturally segues to “here’s the man page, here’s how to use it and search it.”

That tends to give them some confidence that they won’t accidentally cause real damage, and make it seem like they aren’t just typing arcane magic spells, but actually understanding how to responsibly put the pieces together.

Maybe see if you can introduce them to a GitHub project or tool that you think they'll find interesting or useful. I know there are a ton, but I'm not coming up with anything off the top of my head. But if you can give someone a reason to be in the CLI, then they may start to branch out a bit more. I started learning more about the CLI when I started seeing it as cool. Yes, I'm a nerd.

It's not exactly clear to me who is supposed to be more comfortable.

Anyhow:

• Avoid commands that require their own DSL. Most DSLs are ad hoc garbage, in particular when it comes to UX and UI design.

Electroshock. I that is too "harsh" or "inhumane" then a cheat sheet.

At the end of the day the command line is a tool that you are using to do something. If I have to google "how to commit file changes to bitbucket using the command line", I'm probably just going to use whatever GUI tool is available. Or I may do something really silly like manually copy the changes into bitbucket's web interface. If I had a cheat sheet easily available, then I would just look at that. The rest is just practice and repetition.

Just throwing this out there. It really helps if everyone on the team is comfortable enough to ask for help. If you are a manager, it's your job to create this kind of environment. And if you see some newbie data analyst that just learned python and is intimidated by a bunch of software engineers copying a bunch of changes into bitbucket's web interface. Don't tell them that they are doing it wrong or they don't know what they are doing. Just say "hey, there is a much easier way to do that" and then show them. If a tool makes somebody's job easier then they will use it.

Arch has by far the best commands. Need updates? Yay! Need to install? Yay -s! Need to remove and nuke all involved? Yay -Rs!

Fun little utilities: robotfindskitten, cowsay, ponysay, botsay, sl, aafire, bb, viewing videos in the terminal with "mpv, --vo=tct" and perhaps feedgame that comes with orbiton. Htop is also pretty colorful. Lazygit and mc too.

Can't live without oh-my-zsh, powerlevel10k and zsh autocomplete/autosuggestions plugins. It's the first thing I install whenever I'm on a new computer.

And if I'm constrained to Windows (for work) then posh-git and PSReadLine is the next best thing.

Eh, none of this is really addressing the fundamentals of getting comfortable figuring out how to do what you wanna do, which is what in my experience leads to people seeing command line use as magic incantations.

Like, if you’re on windows you know how to figure out how to do what you wanna do, right click a file, look for entries in the context menu, look at the properties, open with, etc.

This works because people fundamentally understand the metaphor behind the operating system.

If you’re in bash and don’t know how to do what you wanna do you don’t need any of this fancy zoomer shit, just use “which”, “man”, whatever your package manager offers and the other commands that had big oriley books written about em.

People need to develop the command line equivalent of the “click around and see if you learn anything” skills.

E: I gave the linked article another read and it really is about setting up a production environment in the command line and not about getting people comfortable with the command line at all.

Like, if someone needs to cut down a tree in their front yard they don’t need to know how to operate a felller-buncher, they need to know how to use an axe handle to judge where the tree will fall and what it will fall on.

No need, GUIs are better for most tasks.

That's a good article. From my observation, there are a few things:

• Necessity. I'm active in communities with people who don't use the terminal until it's an absolute necessity. Like people running unraid, docker, or whatever containerized server. Eventually they need to type commands.
• The prettiness. Yeah, I run oh-my-zsh. It's nice having a setup pretty environment. Some people's only experience might be opening up the powershell default display to run one command... And that is a bad experience.
• Niche commands/programs. Take ffmpeg as an example. It's probably the most powerful media tool that exists, but has no official gui. And it's expansive enough that no GUI really covers what it can do. There are a bunch of other things like this.

Edit: And yeah, git. I've never used a graphical client. Seen a handful in use and don't like it.