Why You Should be Developing On the Command-Line

One of the greatest decisions I made as an engineer was kicking my IDE to the curb and diving into a deep love-affair with the command-line.

Terminals can be scary to the uninitiated: The colors are weird, text often flies across the screen faster than the eye can see, and the looming fear of catastrophic production failure is just a return key away. So then why would anyone want to make the switch? Let’s talk about that.

All through school I used an Integrated Development Environment, specifically, Dr. Java. I would best describe it as ‘cute’ (it was designed for students after all), however it had everything I needed to get the job done; or so I thought. My programs back then were simple: One or two classes, a main method, BufferedReader and some output text. Dr. Java got the job done because the job itself was easy. So what happens when things get more difficult?

Imagine you have a small woodworking business making tchotchkes and other small items. You make 3–5 a day on a bench in your workshop.

Photo by Barn Images on Unsplash

This workbench is your IDE, its focus is assisting you in completing tasks, but it only has so many tools you can utilize. What if you want to start making paper crafts? or blowing glass? What would you do if a big company came along and wanted to buy 100,000 of your little wooden creations? Suddenly your IDE isnt looking so good. Enter the CLI.

If your IDE is an at-home workbench, the command-line is the floor of a massive production facility, ready to be transformed for new tasks at a moments notice. Developing inside a GNULinux environment on the Command-Line is one of the best moves you can make for your Software Development career, so let’s get started.

Background

The majority of running computers in the world today run on some form of GNULinux. GNU being a recursive acronym for “GNU’s not Unix!”, and “Linux” being the actual kernel powering GNU. Together, GNULinux brings everything one would need to get a system up and running, because of this, it attracted a lot of support and wide industry use.

Being familiar in the world’s most popular environment is inherently beneficial, but theres a slew of reasons why devs, myself included, never want to leave. Let’s start with the obvious and work toward the not-so-obvious.

Application Support

Dr. Java is aptly named since at its core it can only compile and run Java programs, but as we all know, theres much more out there than Java. Modern applications have vast technical stacks and utilize a plethora of frameworks and packages. All of these technologies run on GNULinux because thats where they were designed to run, so you can develop in whatever the new flavor of the month is, every month, and never require a new IDE. This is made possible thanks to our best friend:

Vim

VI-Improved is a text editor bundled into the majority of linux systems today, whose power comes from its extensibility and customization. Its basic interface comes coupled with plugins, macros, commands, aliases, code completion, auto-formatting, and more. Common languages and frameworks also frequently release vim plugins for syntax highlighting, so theres really no loss over an IDE, you can even download and install a debugger.

With vim, we’ve solved our workbench problem because we can now hop from HelloWorld.java to main.js to app.rb and beyond, even having all of these files open inside the same window!

Vim can also double as your one-stop-shop for every file in your repository — more on that in another series.

Package Support

Part of the beauty of GNULinux is its package management excellence provided through the Advanced Package Tool (APT). Anyone familiar with Linux knows “apt-get x” is among the first commands run on a fresh install. Everything from editors to cluster-management tools, you can download and update your favorite packages right from the CLI. You can even upgrade your distribution.

Work from Anywhere, Secured Everywhere

With an IDE, you most likely work on your local machine, with your code files sitting in workspaces (or repos if you’re ahead of the game). With this method you’re SOL if you forget your laptop at home, or it crashes. Enter CLI.

Running a remote Linux server as a development box means that all your sweet, beautiful code is available from anywhere, at any time. I can log into my dev server from my laptop’s terminal and have full access, whether I’m in Boston or Hong Kong. It also gives you an additional level of security, particularly if you restrict user access by ssh keys (If you’re unsure what these are, dont worry theres more to come)

Some of my friends have their company’s ENTIRE CODEBASE on their unencrypted laptops. These companies must not be producing any quality code because they clearly don’t care to protect it. That brings me to my next point:

Photo by Brina Blum on Unsplash

Git

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.Git is easy to learn and has a tiny footprint with lightning fast performance.

Git is king, essentially it tracks changes to your files, lets you save (commit/push) those changes and recover them later if you have to. On the command-line, Git becomes even more user-friendly and powerful than inside an IDE, this is because git is installed directly inside your environment.

Some IDEs achieve this as well. There are also Graphic User Interface (GUI) tools for Git such as SourceTree, but something feel inherently wrong with a GUI for git.

I think that feeling can be primarily attributed to confidence, or more accurately, a lack of confidence.

At my first job, the dev team used Subversion (SVN) to control source code. Only they didn’t teach anyone to use it, or even why they should be using it. We created copies of entire databases and edited SQL stored procedures inside them, then replaced the production code with our new version. Yes, you read that right, instead of actually implementing version control, they just assigned one developer per project in the hopes that merge conflicts never arose (of course they did anyway).

When the entire company switched to Git and SourceTree, people were both confused and scared. Confused at what was going on and why it was needed. Whats a Branch? How do I commit, what’s a merge request? Scared because all of a sudden there was a process to developing new features, and this process could potentially mess things up.

Except it can’t! Thats the whole point of Git, that you cant accidentally fubar production code with a push. Nobody was actually afraid, just uninformed, and I believe that fear is key in why many steer away from the command-line as well.

Intangible Benefits

Transitioning from an isolated IDE to the vast open CLI brings with it a breadth of deeper connections to your production/development system, your work, and Software Development if we’re being honest.

You can only be exposed to so much when working within a single application, but the command-line is an open-world ready to be explored. Multitasking has never been easier, processes can be more easily streamlined, it’s more secure, and whether or not you realize it, you’ll become a stronger developer in the process.

At the risk of sounding like a Software Development Elitist: the move from GUIs and IDEs to the command-line is akin to taking off those heavily-relied upon training wheels. While you could have spent your entire life with a set of those bad boys on your back wheel, we both know you are now better off without them.

If this was enough to convince you to make the switch, or even see what this “CLI” thing is about, check out my series on configuring your development environment, it will go over all the technologies mentioned here (and more), how to set them up, use them effectively, and improve your coding efficiency.