Command Line Wizardry
There’s a reason the stereotype exists
There’s a reason that the image of the programmer sitting in front of a terminal emulator using arcane commands is an enduring stereotype. I’ve written before how the command line is inescapable if you’re a software developer. In almost any role that requires you to deal with the technical end of the software industry knowing how to use the command line is a big help.
There is nothing as nerdy-chic as being able to use command-line tools effectively. The bonus is that not only are CLI tools easily portable between environments, from cloud VMs to OS, but they’re also easily automatable. The biggest barrier to the efficient use of these tools usually comes down to people being intimidated or frustrated by them, both of which can be solved by taking the time to learn them. I won’t get into a big list of specific tools, there are all kinds of articles that already do that. Instead, I’d like to focus on what types of tools you really want to have under your belt. Most of these are probably self-evident but I try not to make assumptions.
The Terminal
The most fundamental part of using the CLI is the terminal emulator, usually just called a terminal. This is your gateway to the CLI. Regardless of what terminal you decide to use, you’ll likely be using it for a very long time, so try to be deliberate about your choice. Terminals can be as simple or complex as you like. They can offer things like tabs to keep track of multiple sessions, transparency to look nice, and built-in functions like search. I personally prefer a terminal that looks clean. I don’t want tabs or most of the other fancy stuff. All of those things can be achieved inside the CLI itself.
The Shell
The shell is the next most basic item that everything else is built on top of. Again, which shell you use is fine as long as you know why you’re using it. Be deliberate. The shell is going to be the means by which you interact with your tools, filesystem, and everything else. If you don’t have the time or desire to dig into all of the various shells with their specific pros and cons, my advice is to stick with bash. Bash is ubiquitous being the default shell for most Linux distros, and it’s available for practically every OS out there.
The Package Manager
The package manager is an often overlooked part of the CLI ecosystem. You’re going to have less flexibility around package manager selection because your primary package manager will be dictated by the OS in most cases. While you don’t get to choose the primary package manager used by the OS, you do get more flexibility in choosing the one that you will use for installing your own tools and software. This is a good idea because it separates the package management of your OS from the package management of your personal tools. If you’re anything like most developers you’ll be regularly, if not constantly, installing, updating, removing, downgrading, and in general, creating a big mess in the filesystem. This way you aren’t accidentally screwing with the libraries that your OS depends on. Maybe it’s me but I’ve been bitten too often by adding or removing something that it turns out the OS has a dependency on and things get annoying. I will make this instance the exception to my rule about not recommending any specific tool because there aren’t a lot of OS-independent, portable options out there outside of homebrew. The good news is that it’s available for Mac, Linux, or Windows(using the Windows Subsystem for Linux).
The Editor
Now that you have a terminal, a shell, and you can install tools, you’re going to need to start editing things, e.g., config files. I highly recommend finding a terminal-based editor because once you start seriously using the CLI you’re going to need it. Is it possible to edit locally with a GUI editor, load it onto my EC2 VM, and use it? Of course! That absolutely works. On the other hand, I would much rather simply open the file in situ, make my change, and move on without ever leaving the VM. I’ll leave the flame wars to someone else, I don’t care what editor you use, but I do recommend that it’s something commonly found on most systems, is powerful enough to meet your needs, and doesn’t take you out of the terminal. I also recommend that you learn it well as it makes your life much easier in the long run.
Everything Else
I spent a while trying to come up with more fundamental tools and finally came to a couple of conclusions.
- Everything after the editor depends on your personal workflow
- Your personal workflow won’t develop without deliberate focus from you.
Everything after the editor depends on your personal workflow
Any other tools that I would consider fundamental will only really apply to me. The tools you use and how you use them change depending on your experience, comfort level, and personal preferences. They will change over the course of your career, what you’re working on, and your evolving standards. At one point in my career, I would have declared a terminal multiplexer an indispensable fundamental tool. Then my specific work changed, my habits changed, and while I still use one, it’s not the must-have tool it once was. This can be said about many of the CLI tools that I’ve used over my career. Formatting tools, file managers, network tools, what you use and how you use it, all of it evolves and changes over time, driven by you and your own growth. The only thing I can say for certain is that no matter what I chose to learn, I never regretted investing the time to learn it and it’s always paid good dividends across my career.
Your personal workflow won’t develop without deliberate focus from you
That’s a misleading statement. It will grow and develop without deliberate focus from you. The difference is how it will develop. Without deliberate focus from you what will happen is that you’re leaving your professional growth to the roll of the dice. If you get lucky, you’ll stumble around and step into a pot of gold. If you aren’t, you’ll learn habits that will hamper you for years. The most likely scenario is that you’ll be a mediocre developer. And yes, this is true without the CLI focus. In my experience, the CLI is an amplifier for intentional learning. Six months of deliberate learning while using the CLI vs six months of flailing around on the CLI is the difference between taking thirty seconds to locate a file, and three seconds to locate a file.
Closing Thoughts
This may have been a little rambling but if you’ve made it this far, I appreciate your persistence. While writing this article, I realized that the biggest difference for e personally was deliberate focus and intent. Beyond using the CLI, or professional growth, being intentional in your pursuit of whatever it is you’re chasing is key. There have been times in my life when I lost that deliberate intent, in my work and my personal goals, and flailed about not really accomplishing much but not really losing ground. Just..stagnating. When I would wake up and notice I realized that I’d wasted a lot of my time getting nowhere. After regaining my focus I would accomplish more in a month than I had in the past six. Don’t be me. Keep your focus, be deliberate, and whatever you do, do it with intention.
If you made it this far, give me a clap or a follow so I know if you found this interesting or useful.
