Learning to use the command line

I learned to use the command line in my early thirties.

That’s later than most people who do what I do, and it reflects an embarrassing gap in my self-education. I’d been building websites since 2001. For most of those years, my workflow was entirely GUI-based: text editor, browser, FTP client, repeat. Everything had a button.

Then Sass arrived, then Grunt, then Bower, and suddenly everything had a terminal command.

Why I resisted

Partly inertia. When your existing workflow produces good results, the activation energy to change it is high. Partly intimidation — the command line felt like a different discipline, one I’d missed the required course for. The error messages were terse and unhelpful. Nothing had a visual affordance to guide you.

What finally pushed me over was Sass. I’d watched CSS preprocessors get popular for a couple of years before trying one. When I finally did, the productivity gain was immediate and obvious. Variables, nesting, mixins — CSS that could be refactored like real code. I wanted it badly enough to learn whatever it took.

What I actually had to learn

cd and ls. How paths work. What a process is and how to kill one. What npm install does and why node_modules weighs more than most databases. How to read an error message that assumes you know things you don’t know yet.

The terminal is just another interface. It happens to be a text-based one that rewards learning its conventions. Once I stopped treating it as foreign and started treating it as a tool with a learning curve, it became the environment I spend most of my working time in.

The deeper lesson

For ten years I’d built websites without version control. I committed my first changes to Git in 2013 and can now barely imagine working without it. The things I’d been avoiding because they seemed like infrastructure, not craft, turned out to be part of the craft.

The best tools look like overhead until they become load-bearing.