TL;DR: Touching the mouse is often bad for productivity. Do it as little as possible or not at all.

I am a designer by trade, extremely lazy, and I never studied computer science or did any sort of programming in college. I did study Studio Art.

I might talk about some technical things, but I’m just trying to figure out how to design the most amount of great stuff in the least amount of time with the least amount of effort possible.

Terminal and command-based text editors are just tools that can help us build beautiful products. They shouldn’t seem scary. They are here to help.

Computers are here to do the boring stuff for us. And we should let them. Because the less time we spend doing boring dumb stuff, the more time we can spend thinking about fun things. Like memes and gifs and cats.

So what is one way to get computers to do a lot of heavy lifting for us? Command-based text editing.
Wut?
Exactly.

A brief primer.

What is command-based editing?

Generally speaking it involves editing text without using your mouse. If you’re familiar with the improved speed that keyboard shortcuts provide you in something like photoshop or illustrator - you’re going to love using a similar model to manipulate text on the page.

So, what are command-based editors?

Well, there are several command-based text editors out there. vi/vim, emacs, and nano/pico are some of the more common editors you may have heard about before. All of them are pretty great in some regard. But I know vim the best. And my third grade teacher taught me to write what I know so that’s what I’m going to stick with trying to explain here.

Okay but what are these commands you speak of?

Haha yeah I should explain that. Text editing, is just a bunch of common discreet tasks. Commands do things like: delete characters, copy lines of text, jump to other occurrences of a word in a project, paste saved blocks of code or text, and navigate between files. All without leaving your keyboard.

What is this vim you speak of?

Vim is a text editor that is available on all unix systems (as well as some others). If you are on a Linux or Mac box right now, vim is already installed on your machine. Its ubiquity is one of the many reasons I like vim. I can step into any unix environment and have a familiar text editing environment.

Wait why are we talking about editing text at all? We just want to design stuff.

That’s a good question. And I can only answer it for myself. As a designer, I write a lot. I write code. I write down my ideas. I write emails to colleagues. I write copy for websites and applications. Sometimes I write documentation for things I’m designing. Much of what I do just boils down to writing and then revising / editing text. Since it is where I spend the bulk of my time, I figure it’s not the worst investment of my time to try and make the process a bit more efficient. Mostly because of the math behind the graph below. But also because it hasn’t been that hard. And in fact it’s been a lot of fun.

The XKCD guide on when to stop and automate something

XKCD 1205 - Is it worth the time?

When you think about it, editing text is really a constant series of blackholes for your time. And that graph hopefully gives you an indication of how much time you have already lost and how much time you might lose in the future. There are countless routine tasks that you are losing between 1-10 seconds on. You might not even realize it yet. Just the time it takes to move your hands from the keyboard and place them on the mouse and back is > .5 seconds. How many times do you think you touch your mouse a day to grab a selection of text?

It’s not just the increased amount of time it takes to use the mouse. It’s also the cognitive dissonance a physical action introduces to your workflow. I find I am a much more passive computer user when I am using a mouse. I start to perform specific actions but am easily distracted.

I can’t tell you how many times I go to check my email and as I bring the browser up I’m confronted with an open tab with an article I wanted to read but didn’t get a chance to. All of a sudden I forget what I was doing. If I just had a command that brought me straight to my email, I’d be less likely to be run offtrack from what I set out to do. Since I can’t commit using a mouse to muscle memory, I can’t internalize the action.

Commands, on the other hand I can commit to muscle memory. And since muscle memory is internalized, I’m more likely to be able to quickly get my task done without losing my train of thought. This makes editing text start to feel a bit more like playing an instrument and a little less like chasing your own tail.

When it comes to learning code, the more efficiently I edit text, the faster I can learn. In essence I’m just shortening the feedback loop between when I have a question about how a block of code will work and when I have an answer. This pays off in dividends. Because no matter how good you get at writing code, you will always have questions that need answers.

Editing code with ease also lets me iterate through design ideas quickly. I know things I want to try.

What if the color scheme was reversed?

What if there was different copy here?

What if we changed the main image? What if we changed all the images to just cats?

What if we used a different navigation pattern?

What if this text was right aligned?

What if that text was left aligned?

What if ALL the text was centered?

What if we used a different grid system here?

What if the copy was different again?

What if the labels are above the inputs?

What about if we put the labels to the left of the inputs?

This probably is not the list of questions you ask yourself, but the point is that you ask yourself questions. And you shouldn’t have to wait long to see the answers. If you’re laboring over making changes in code to test your ideas, take some time to invest in learning your text-editing tools. I promise your future self will thank you profusely.