People ask me occasionally why I prefer doing things in the terminal when there’s a perfectly good GUI right there. It’s a fair question. Tooling has improved enormously. VS Code is genuinely great. The JetBrains IDEs have features I couldn’t live without. And yet.

The composability argument

The terminal’s fundamental advantage is composability. Each tool does one thing and pipes to the next. This sounds like a cliché because it’s been repeated since the Unix philosophy was codified in 1978, but it remains true and powerful in practice.

Example: I want to find all files in a project modified in the last 24 hours, exclude node_modules, and open them in my editor.

find . -newer yesterday.log -not -path '*/node_modules/*' -type f | xargs code

There is no button in any GUI that does this exact thing. But every piece of that pipeline exists as a standard tool, and combining them is immediate and composable in a way that no visual interface matches.

On muscle memory

After years of shell use, common operations take zero conscious thought. cd, ls, grep, git log --oneline, piping, redirecting — these are as automatic as typing. Switching to a GUI for file operations requires reading menus, clicking through dialogs, and navigating hierarchies. It introduces friction at the point where I’m trying to think about something else.

The investment in building that muscle memory pays dividends for years.

Reliability and consistency

The terminal works the same everywhere. It works on the server I’m SSH’d into at midnight debugging a production issue. It works on the minimal Docker container that doesn’t have a GUI. It works on a machine I’ve never touched before that has only the basics installed.

GUIs are not portable in the same way. They require installation, configuration, and licensing. A fresh server has bash. That’s enough.

Where IDEs win

This is not a manifesto against IDEs. For code navigation (jump to definition, find all references, inline type info), the IDE model is genuinely better. Debuggers with proper watch variables and stepping are better in an IDE. Language servers have made editor tooling so good that the gap has narrowed significantly.

My actual workflow: a terminal pane for everything system-level (git, file ops, running scripts, SSH), and VS Code for the editor features that require semantic understanding of code.

The aesthetic angle

I’ll be honest: there is also an aesthetic component. A well-configured terminal with good colours, a minimal prompt (I use Starship), and tmux for session management looks and feels good in a way that I find calming. This matters. You spend a lot of time in your tools.

# ~/.config/starship.toml snippet
format = """$directory$git_branch$git_status$character"""
[character]
success_symbol = "[❯](green)"
error_symbol = "[❯](red)"

I’ve been running some version of this configuration for five years. It gets out of the way and lets me focus on the work.