Skip to content

The long way to become a small, angry Vim user

As a software engineer, there are unspoken expectations you need to fulfill. You should be able to write tests. You should know the basics about data structures and algorithms. And of course, you have to know how to use Vim. When your colleagues casually mention Vim commands or what they are yapping and dapping in the code, you nod along awkwardly, hoping they don’t ask you to demonstrate. The fear of being exposed as a Vim noob is real, so you decide to learn it, if only to avoid the shame of not knowing how to quit the editor.

But deep down, you know there is another reason for your desire to learn Vim. There’s a certain je ne sais quoi that comes with being a Vim user. The intense focus, the blazing-fast typing, the mysterious key combinations – it all screams “I’m a real software engineer.” You want in on that elite club, where the true masters of the craft reside. Learning Vim is your ticket to belonging.

Step 1: the blinking cursor

You open the terminal. You cd into the directory you want to work with. You type vim and hit enter. And you see the glorious blinking cursor. And nothing else.

Okay, there is some basic information about Vim, but not much else. No files, nothing. Only the glorious cursor. You try to follow some tutorials you find online, but even with 50% speed, your semi-arthritic fingers (gotta thank VS Code and your mouse for that) simply can’t keep up.

Then you learn about VimTutor and found your entrance into the Vim world. You try to finish it multiple times, eager to get better. But when you actually try to use your newly gained skills in a project, you fail miserably. You’re stuck with hjkl.

Step 2: learning the first motions

Annoyed by your lack of speed in using Vim you decide to learn Vim motions. They are the reason for Vim’s popularity. Jumping from one line to another, swiftly deleting a whole paragraph and changing everything inside quotes in the blink of an eye. This is what using Vim is about.

Some might try to learn the motions first (with an extension for their IDE) and only then adapting Vim (or Neovim) as their IDE. But not you, you want to feel the grind, the slowness of adapting both to a new way of life and throwing away the training wheels provided by VS Code.

The tutorials you watched mention f, t, $ or %, so of course you want to incorporate them in your repertoire. In reality, you spend hours upon hours trying to remember whether it’s j to go down or k to go up. Your brain frantically cycles through the mnemonic devices you’ve read about, while your fingers fumble around the keyboard like a newborn giraffe learning to walk. But hey, at least you’ll soon be able to impress your friends by navigating code at the speed of a tortoise on sedatives.

But the promise of increased productivity and efficiency is what keeps you going. You’re determined to join the ranks of these Vim wizards with their split keyboards and DVORAK/Colemak layouts, even if it means hours of frustration and countless online tutorials.

Step 3: embracing Vim

You will start to use Vim for everything. When you previously used Nano to edit files in a production server, you switch to Vim. You inevitably will try to edit text outside your editor like emails with Vim motions. You will send gibberish messages to colleagues like fRrLwwciw that you meant to use in Vim, but your focus was wrong. You might get laughed at at this point, but every Vim user has been there before.

Whenever you talk about coding, you have no choice but drop the obligatory “I use Vim btw”, regardless of if the other person has no idea what Vim even is. You just can’t stop thinking about the wonders of Vim.

The next step will be the magic of macros - both macros you wanted to start and macros you started by accident. At some point, you stop doing redundant tasks, you’re better than that. Macros are the way to go. You’re one step closer to becoming a Vim wizard.

Step 4: creating your own IDE

To be fair, plain Vim is tough. It doesn’t help you with suggestions, syntax highlighting or similar quality of life features we love from our IDEs. You look into VimScript, get annoyed and turn to Neovim. You learn Lua, just to craft your IDE exactly to your liking.

Hours turn into days as you scour the internet for the best Neovim plugins, color schemes, and key bindings. You find yourself knee-deep in a rabbit hole of GitHub repos, StackOverflow threads, and Reddit discussions, all in the pursuit of Vim enlightenment. Your friends start to wonder if you’ve forgotten how to use any other software besides a text editor.

Once you’ve got your Neovim setup just right - with the perfect blend of language servers, fuzzy finders, and syntax highlighters - you’ll be unstoppable. Or, at the very least, you’ll look like a real software engineer, sipping coffee and staring intently at your terminal while everyone else is content with their boring old IDEs.

Now that you’ve finally embraced the ways of Vim, the only thing missing is a beautifully groomed mustache to be a complete software engineer. After all, what’s a true Vim master without a finely curated facial hair statement?