Beyond cd and ls: A Developer’s Survival Kit for the Terminal
Source: Dev.to
I know my job title doesn’t say DevOps engineer, but I handle enough of the Software Development Life Cycle (SDLC) that I need to know some DevOps. “Don’t ship on Fridays” is real—shipping on a Friday is the easiest way to mess up your weekend, even if you sometimes have no choice.
It’s 4 pm on a Friday, the deployment pipeline is red, the cloud dashboard is spinning endlessly, and it’s just you, your dark terminal, and a prayer that the server will respond. In those moments the GUI can’t save you; you need the raw speed of the Linux command line. Over the years I’ve built a survival kit of commands that go far beyond cd and ls. They help with frozen processes, disk‑space issues, tracing API failures, and everything in between.
tail -f
Setting up the scene
You deploy a new feature and a user reports it’s not working. The dashboard is delayed by five minutes, and you need to see the error as it happens.
The command
tail -f /var/log/nginx/error.logWhy I use it
Streams the log file to your screen in real time. I usually open this in a split terminal, trigger the bug on the frontend, and watch the error stack trace fly by. It provides the fastest feedback loop.
grep -r
Setting up the scene
You have dozens of log files or a massive codebase and need to find every occurrence of a specific variable or error code such as "payment_failed".
The command
grep -r "payment_failed" ./srcWhy I use it
Opening VS Code to search on a remote server is slow. Recursive grep searches every folder instantly and tells you the exact file and line number.
htop
Setting up the scene
The server is lagging and requests are timing out. You suspect a memory leak or a rogue process eating CPU.
The command
htopWhy I use it
Unlike the plain top command, htop provides a colorful, visual bar chart of CPU and RAM usage. You can quickly identify which process—often a stuck Node.js script—is hogging resources.
df -h
Setting up the scene
Your database crashes out of nowhere. No error logs are being written and the server behaves oddly.
The command
df -hWhy I use it
Shows disk free space in a human‑readable format. Nine times out of ten, crashes are caused by logs filling up the drive. This command saves hours of debugging ghost bugs.
netstat -tuln
Setting up the scene
Your app reports “Deployment Successful,” but visiting the URL yields a “Connection Refused” error.
The command
netstat -tulnWhy I use it
Lists all ports the server is actually listening on. It quickly reveals mismatches, such as an app listening on port 3000 while Nginx expects port 8080.
history | grep
Setting up the scene
You fixed a complex bug three days ago with a long Docker command, but the bug reappears and you can’t remember the exact syntax you used.
The command
history | grep "docker"Why I use it
You don’t need to memorize long commands; just remember a keyword. This searches your entire command history and shows you what you typed previously—your external brain.
curl -v
Setting up the scene
You are debugging an API but aren’t sure whether the issue is the firewall, browser cache, or the code itself.
The command
curl -v http://localhost:3000/api/healthWhy I use it
curl fires a request directly from the server. The -v (verbose) flag shows the handshake, headers, and raw response. If this works but the browser doesn’t, the problem is likely the firewall or Nginx configuration, not the application logic.
kill -9
Setting up the scene
You found a stuck process using htop, but it refuses to close gracefully.
The command
kill -9 <PID>Why I use it
Forces the process to stop immediately. It doesn’t save data or clean up, so use it only when a process is completely frozen and blocking a port. Replace <PID> with the Process ID shown in htop.
The terminal used to terrify me. I always wanted a graphical interface, but after a few deployments you realize it’s not just sysadmins who need this stuff. Once you know what you’re doing, you can be very fast.