Aliases, History, and a Bash Script Named 'go': Small Terminal Habits That Built My Career

Ask a developer about their career-defining moments and you'll hear about the big stuff: the rewrite, the migration, the framework bet that paid off. Ask me, and I'll tell you about a bash alias.

Somewhere around year three of my career, I typed [git](https://en.wikipedia.org/wiki/Git) checkout -b for the ten-thousandth time, felt a flash of irritation, and spent ninety seconds creating an alias. That ninety seconds started a slow avalanche. Here are the five small terminal habits that, stacked on top of each other, became the engineer I am.

1. Aliasing Everything I Type Twice

It started with git. Then gco for checkout, gst for status, a serve alias that spins up whatever the current project needs. The habit itself is trivial. What it taught me wasn't: if a friction point annoys you repeatedly, you're allowed to fix it. Most engineers tolerate tiny irritations for years. Learning to notice them — and to believe a two-minute fix is worth doing — is the seed of every automation instinct I have.

2. Treating Shell History Like a Knowledge Base

I stopped hitting the up-arrow a hundred times and started using Ctrl+R religiously, then graduated to a fuzzy-searchable history tool. Suddenly my terminal remembered every incantation I'd ever wrestled with: the weird find command, the exact [kubectl](https://en.wikipedia.org/wiki/Kubernetes) flags, the curl with the auth header I always forget.

The deeper lesson: your past self is your best documentation. Most people solve the same problems repeatedly because they never built a system for remembering. History discipline turned my terminal from a command runner into a searchable log of hard-won answers.

3. Scripting the Second Repetition

My rule: if I do something manually three times, it becomes a script. The first script was dumb — a deploy helper that ran the same five commands in order. Then a database-reset script. Then one called simply go that sets up a fresh clone: deps, env vars, migrations, done.

Each script was an hour of work saving minutes per use. Terrible ROI on paper. But every script also forced me to understand the process well enough to encode it. You cannot automate what you don't comprehend, so scripting became my forcing function for actually knowing how things worked — which is most of what people mean when they call someone senior.

4. Living in One Directory-agnostic Workflow

I trained myself to never depend on where I am: aliases that work from any repo, a jump command that lands me in the right project, consistent naming everywhere. It sounds like OCD; it's actually portability. When your environment is uniform, your brain spends zero cycles on navigation and all its cycles on the problem.

This is also the habit that made switching teams and jobs painless. My workflow traveled with me, because it was mine — not the company's.

5. Reading the Man Page Once a Week

The least sexy habit on the list. Once a week, I'd pick a tool I use constantly — [grep](https://en.wikipedia.org/wiki/Grep), find, tar, ssh — and read its docs for ten minutes. No agenda. Within a year I knew flags and combinations that made colleagues assume I was some kind of wizard.

I wasn't. I'd just read the manual. The compounding is absurd: ten minutes a week is under nine hours a year, and it changed the ceiling of what I could do without Googling.

The Point Isn't the Terminal

None of these habits are about the terminal, really. They're about a posture toward your own work: notice friction, fix it small, remember what you learn, and let tiny improvements stack. Frameworks come and go — I've watched three JavaScript ecosystems rise and fall. The habits compound through all of them.

Big career moves get the applause. But careers are mostly built in the ninety-second decisions nobody sees.