At my first job out of college, I met a lot of junior developers who could sort of get by in a Unix CLI, but didn't know anything except the very basics and did

At my first job out of college, I met a lot of junior developers who could sort of get by in a Unix CLI, but didn't know anything except the very basics and didn't much like it. I was a Linux hobbyist from the age of 12, so I thought that sucked. Since the company had a practice where developers could give their peers educational talks, I decided to demo some of the things I use to make my Unix command line environments feel really great to work in. I found that pointing CLI-shy devs to a nicer shell designed with ease of use in mind (Fish) and some basic navigation tools like fzf and autojump got a good chunk of them genuinely excited to learn more about the command line and make their environments more comfy. I also reviewed the available in-terminal documentation tools including those they likely hadn't seen in school (e.g., tldr, bro-pages), and I think that helped make clear how efficient exploring the command line from the command line can be. (Nowadays I'd also direct them to explainshell.com and some other web resources, though I think emphasizing the 'in-band' stuff is important.) The next day, and every now and then for some time, I saw them reading the docs, writing their own little plugins and scripts and aliases, customizing their prompts, and so on. I knew about it because they sometimes even called me over to show off! It would have been a shame to blow them off because, not having seen how it can be delightful to use, they saw the terminal as something to be avoided. They were smart, capable people who just hadn't encountered a good enough pitch yet. Once the environment is comfy, learning individual tools in it becomes a lot less intimidating and more appealing to people. But you have to show them how good it can be and offer them a decent starter kit. :)