Most people interact with computers exclusively through graphical interfaces: point, click, drag, scroll. It works. It’s intuitive. And for many tasks, it’s the right choice. But if you work with technology professionally, avoiding the command line is like a mechanic who only uses an adjustable wrench. You can get some things done, but you’re leaving your most powerful tools in the drawer.
This isn’t a religious argument. Both interfaces have their place. But I’ve spent twenty years watching people struggle with tasks that would take seconds on the command line, and I want to make the case for why learning it is one of the highest-leverage investments you can make.
Where the CLI Wins
Speed
Clicking through menus takes time. Every GUI operation requires you to find the button, position the cursor, click, wait for the response, and repeat. A CLI command executes in the time it takes to type it.
Rename 500 files? A GUI means clicking each one. The CLI:
for f in *.txt; do mv "$f" "${f%.txt}.md"; doneDone. All 500. In under a second.
Safety
With the keystroke saving tab-to-complete in most command line shells, ~/.zshrc aliases, scriptability, and not using a pointing device, you can avoid or minimize repetitive motion injuries.
Repeatability
A CLI command is text. Text can be saved, shared, version-controlled, and executed again identically. If you solve a problem on the command line, you have the solution as a string of characters that works forever.
A GUI workflow? You’d need to write a step-by-step document with screenshots. And if the UI changes in the next version, your documentation is wrong.
Automation
You can’t automate a mouse click reliably (AutoHotKey aside). You can automate a command. Every command-line task is one step away from being a script, and every script is one step away from being a scheduled job.
This is the fundamental advantage: the CLI is programmable. The GUI is not.
Composability
UNIX philosophy: small tools that do one thing well, connected with pipes.
# Find the 10 largest files in the current directory tree
find . -type f -exec du -h {} + | sort -rh | head -10Three separate tools (find, sort, head), composed into something none of them could do alone. GUIs don’t compose like this. Each application is its own silo.
Remote Access
SSH gives you full control over a remote server through a terminal. The server doesn’t need a display, a window manager, or a desktop environment. It just needs an SSH daemon. This is why every server in every data center on the planet runs headlessi; there’s no screen, no keyboard, no mouse. Everything is managed via CLI over SSH.
Try managing a remote server through a GUI. You’ll need a VNC or RDP session, which is slow over the network, resource-intensive on the server, and a security risk.
Resource Efficiency
A terminal uses almost no system resources. A GUI application with its windowing toolkit, rendering engine, and event loop uses orders of magnitude more. On a server, those resources should be running your application, not drawing buttons.
Where the GUI Wins
Visual Tasks
Image editing, video production, graphic design, data visualization; anything where you need to see a visual result and interact with it spatially. You’re not going to edit photos from the command line. (Well, you can with ImageMagick, but you probably shouldn’t for creative work.)
Discoverability
GUIs show you what’s possible. Menus list available actions. Buttons label themselves. You can explore an unfamiliar application by clicking around. A CLI requires you to already know (or look up) what commands exist.
This makes GUIs better for beginners and for applications you use infrequently.
Complex Configuration
Some configuration tasks are genuinely easier in a GUI, particularly when there are many interdependent options and you benefit from seeing the current state while you change it. Network equipment configuration interfaces, cloud console dashboards, and IDE settings panels fall into this category.
Presentation and Collaboration
When you need to show something to a non-technical person, a GUI is usually clearer. A dashboard with charts communicates more effectively than a table of numbers in a terminal. A formatted document in a word processor is more presentable than a text file.
The Real Answer: Use Both
The most effective practitioners use both. My workflow looks like this:
-
CLI for: file management, server administration, Git operations, scripting, automation, text processing, searching, building and deploying software, managing infrastructure, database queries
-
GUI for: web browsing, email, image viewing, video calls, monitoring dashboards, IDE features like debugging and visual diff.
The CLI handles the heavy lifting. The GUI handles the visual and collaborative tasks.
Getting Started with the CLI
If you’re CLI-curious, here’s a practical starting path:
Learn These Commands First
cd # Change directory
ls # List files
pwd # Print working directory
cat # Display file contents
grep # Search for text in files
sed # Edit text
awk # Process text
find # Find files
mkdir # Create directories
cp # Copy
mv # Move/rename
rm # Delete (careful!)
chmod # Change permissions
ssh # Remote connection
man # Read the manual for any commandThese fourteen commands cover the majority of daily file and system operations.
Learn These Concepts
-
Pipes (
|): Send the output of one command as input to another. -
Redirection (
>,>>): Send output to a file instead of the screen. -
Variables: Store values for reuse.
-
Loops: Repeat operations across multiple items.
-
Exit codes: Every command returns a status (0 = success). Use this for error handling in scripts.
Practice With Real Tasks
Don’t learn the CLI in the abstract. Use it for real work:
-
Navigate your project directories from the terminal instead of a file manager.
-
Use
grepto search your codebase instead of your editor’s search function. -
Write a shell alias for a command you type frequently.
-
Manage Git from the command line instead of a GUI client.
Each time you reach for the mouse, ask yourself: “Could I do this from the terminal?” If yes, try it. It’ll be slower the first time and faster every time after that.
Keyboards: Your physical interface to your command line interface
When you regularly use the CLI, a good keyboard makes working a pleasure.
Keyboards are quite subjective. Some people like the split, angled, ergonomic keyboards. Other people want the smallest keyboard their hands can fit on. I prefer an old-fashioned, clicky, 108-key keyboard with number pad. It’s also common to work on several devices at the same time, so multiple Bluetooth channels or USB connections is nice. For some applications, my paranoia demands a physical connection; I don’t want to risk the chance that someone can intercept and decrypt my keystrokes when they are broadcast over radio frequency.
This is the best keyboard I have ever used. It has the clicky keys, a selector knob to switch between USB, RF, and Bluetooth. It also has a volume knob, 2 macro keys, and a fun, retro look. It has some very retro, detachable gaming buttons and joystick. On the right side is a magnet so this number pad docks to it. It has the same 3 outputs, and can operate independently as a calculator. Both have rechargeable batteries so they can function wirelessly. For stylish ergonomics, I also have this wrist rest.
The Long Game
Learning the CLI is an investment that pays dividends for your entire career. GUI applications come and go. The command line hasn’t fundamentally changed in decades. The grep you learn today works the same as it did in 1973 and will work the same in 2033. The scripts you write are portable across machines, operating systems, and decades.
Every hour you spend learning the command line makes every subsequent hour of computer work more efficient. There is no comparable investment in technology skills with a better return.
| This article contains affiliate links. They are for products or services that I believe in, cost you nothing to use, and help support this site. |