Learn the command line

Dear new developer,

I remember the first time I saw a senior engineer struggle with the command line. He was a new hire and was getting up to speed on a new project. If memory serves, he was trying to get his IDE set up for a java project.

I noticed him with the command line open, trying to remember how to move around directories, and wondered why he was having such trouble. (Probably I felt the same way some developers feel about me when I struggle with CSS or cutting up a PDF or reading C–“how could you be a developer without understanding this?”.) I never talked to him about this, but it cemented in my mind why a new developer should learn the command line inside and out.

It’s a baseline.

The command line interface (CLI) will always be available. Wherever you are (unless you are on an old mac, pre MacOS X, in which case, why?).

Unlike some of the skills I mention above, knowing how to navigate the command line will make your life easier as a developer no matter where you work or in what platform or capacity. It’s a general purpose skill, like understanding how to use version control or learning a text editor.

Understanding the command line and being able to use it has the following benefits. Let’s take a simple task–I need to move a file into a directory, change the permissions on that file, then look through the file for a certain phrase (say, “rosebud”). With a CLI, I can:

• accomplish the task in less time. I can move files, change file permissions, and look through files far quicker with command line tools than I can with any GUI (graphical user interface) tools. (There are any number of other tasks I can accomplish more quickly, as well.) The kicker is, of course, the first few times I do this, I will be slower on the command line than I would have been using a GUI. This is because you have to learn the CLI and the cues to help you do so are minimal. You of course also have to learn a GUI (anyone who’s ever shown someone a GUI for the first time know that) but there are more cues on what is the right behavior in a graphical context. But once I have it down, the typing the commands will be much quicker than moving the mouse.
• make tasks repeatable. If I’m trying to move a file, change its permissions, and see if it contains “rosebud”, I can do this once easily in the GUI, using the mouse and menu commands. But doing this task regularly, whether once a day, once a month or once every time a piece of software is released is quickly going to get tedious. I can, on the other hand, do it once in the CLI, and then take the CLI commands and put them into a script (a text file that becomes executable). Then that same set of commands will be run every time I run the script. This may not matter if task is simple (as is my example of only three commands is), but if it is complex, getting it right once and having it run perfectly every time thereafter will be a huge time and energy saver. If executing the task is common, then you will save time because you will run it often. If executing the task is rare, you will save time with a script because you won’t have to remember how to run the command.
• share tasks with other people. Yes, you could record a video of yourself clicking through a GUI to move the file, change its permissions and look for “rosebud”. Or you could document the actions in detail and send the doc over. Or if you are colocated, you could show them. But it’s much easier to just send someone else an executable script or set of commands that they can examine and run. As long as they have access to the same command line programs, you’re going to get the same results. (Beware different versions of the same command line program, especially if you are using esoteric commands or working on different operating systems.)

Hopefully I’ve convinced you to learn the command line. Now, what are good ways to learn it?

I think that one path is to just jump in. Find the “terminal” program if you use a mac, or the “cmd” program if you use windows. Open it up. Then google for “command line tutorial <platform>” and work through one of those. I always work best when I have a real task, so think of something you do often (for example, opening up a number of files for a project, moving files to a backup directory) and do it once in the GUI. Then do it once in the command line. Then make a script for it. See how that feels. If you are scared of messing up your computer, install a VM or boot up a cloud server (most cloud providers will give you a small server for free for a while). You can’t screw up a VM that you just started, and if you do, just destroy it and start a new one.

Another option is to think about mapping between the GUI/IDE and the command line. Every time you do a task in the GUI or IDE, drop down into the command line and try to replicate that. From something as simple as moving a file to something as complex as a full fledged deployment or compilation of a large project.

As you get more advanced, you have the option of sharing your keybindings between your editor and your shell. Just google “keybindings <editor> <shell>”. I use vi keybindings for my bash shell and it lets me move around the command line with ease and speed. And every time I learn a new way to move around the editor, my CLI usage gets better.

The command line is underneath almost every computer. Learning it will save you time and let you leverage knowledge. Well worth the effort.

Sincerely,

Dan

PS I would be remiss if I didn’t link to this essay about the command line.