I am a Vim user. And a Vim fan.

I was fiddling around for some time, you know, just knowing the basics, because it is convenient to do small changes on servers without having to worry about installing anything. Just the basics, insert mode, some search, save,

and a couple more things. Then, around two years ago, I decided to give it a try as my main editor, after watching a presentation of a co-worker (my boss, actually) about how to use Vim (he has been using Vim for around 20 years)

At the beginning, it is quite difficult, to be honest. You have to relearn everything about editors. But I was doing OK after one or two weeks, so I kept using it. I was also forcing myself into improving my usage, reading about it and learning tricks…

Then, after a while of using it and read a lot of instructional material (I cannot recommend “Practical Vim” by Drew Neil strongly enough. It’s a FANTASTIC book), everything started to make sense. Let’s be serious, the problem with Vim is not exactly that is “difficult” per se, it’s that it is so alien to any other text edition experience, that you have to forget everything that you know about how to edit text. That’s why I don’t agree that the Vim learning curve is a myth. Because, when we first heard of Vim, we already have 10+ years of using things like Word, NotePad or Gmail to write text. We need time to assimilate how to edit text “the Vim way”. And that takes time to assimilate, as your muscular memory works against you.

And, yes, the Vim way is awesome. But it is awesome not for the reason that usually someone will think at the start. There is the perception that Vim is awesome because is fast. It is not.

Well, it can be really fast sometimes, like performing complex replacements or macros. And that is absolutely magical. But that is not something that I use constantly, and it only save a noticeable amount of time when those operations should be performed tens, maybe hundreds of times. Of course, it also will reduce greatly boredom of repetitive tasks. It is still a great win. But those are exceptions on your day-to-day operation. If they are the rule, probably you should consider a change of job!

In my mind it sort of compares with knowing how to touch-type. Developers, contrary to Hollywood opinion, are not typists from the 50s, typing tirelessly for hours and producing massive streams of characters. We write small burst of code between long reading and thinking sessions. The best analogy that I heard (I can’t find the reference on Internet right now 😦 ) is that we act like samurais in anime, just staring at the code, analysing them carefully. Thinking, thinking, thinking. And suddenly, in a blink of an eye, we draw our sword and hit with precision, to then stand still, in a dramatic pose, as we see our enemy cut in half. Touch type is not important because it allows us to generate double or triple number of words per day. It is important because it eases the process of getting out of thoughts at that critical moment. You don’t add speed, you add control and relax. You don’t have to manage the stress of getting your body to press the keys and some symbols appear on the screen. You just think on writing something and it appears on the screen, with your body handling the problem and freeing your mind.

Using Vim feels similar to me. When I have to use another editor, I am thinking in terms of characters, maybe words. But my mental flow is more or less the following:

I have to change the parameters of this function. Decide action: I’ll delete those words between the brackets and write the new params. Cursor just right to the starting bracket. CAPS and ALT and right, right, right. Good.* Hit Delete Write the new params. Done.

* This can also be deleting each character, but I’m trying to be an “advanced user” here.

Mentally, I get the following voice inside my head, as I move through the text:

While, in the Vim realm, the process is more like the following:

I have to change the parameters of this function. Decide action: I’ll change those words between the brackets. Operation change between brackets Write the new params. Done (hit ESC)

Here, the part when I spend the most energy is in operation 2, determining what is the part I have to change. In this case, is easy, as I set as example something between brackets (ci( will do), but it is a quite common case when you’re editing code. But it can be more difficult, like “up to the character X (coma, semicolon)”. I am getting better with practice, but it is not automatic, I have to think about it. That’s the part where the learning curve kicks in. It’s not about knowing what to do. It’s deciding what (of a myriad possibilities) option is the correct one. Or even if there is one that you don’t know yet that will work better. Move one character at a time? A word? A block? Count the number of lines? Etc… Deciding the proper action without much effort, instinctively, takes practice and conscious teaching yourself possible moves (that you can reuse later for more operations). After all, the code tends to repeat patterns, and there are a lot of actions that helps with specifics of the language, like indenting in Python.

Anyway, I find this way of operating with the text causes much much less friction in my mind, ad I can see how it gets easier and easier as I am more experienced. Because I am thinking in actions. Actions that make sense. I am not rearranging random characters. I am performing specific actions that make sense semantically. I do stuff with words, phrases, paragraphs, blocks, functions, parameters inside brackets, etc…

And that makes a lot of sense. My mind thinks naturally on that kind of actions, so it’s more natural than rearrange some sort of symbols on a screen.

All the part of reading and thinking takes the same time, and actually using the editor to change the code is a small part of my working day. Saving some keystrokes is not going to allow me going home two hours earlier. And trying to optimise in keystrokes can take a lot of time just thinking.

But, when I make a change, I am able to do it spending less mental energy. It feels more natural. I need to think less in the characters. The editor gets less into the way of getting the text into the image in my mind. I still have to think about what action to do, but it is a much more natural approach.

And that is the power of Vim. Not that is fast. Not that you can do a magical operation with few keystrokes. That it stays out as much as possible of the way between you and your code. That maps your thoughts once you know how to use it.

And that’s why I don’t really care about Vim “speed”. I am not “faster” using Vim. I do not generate noticeable more code at the end of the day. But I generate it with less effort and caring more about the quality than battling with my keyboard. I am more relaxed, more in control, focused in what matters. Caring about getting stuff done. More productive. That’s Vim killer feature.

UPDATE: There is some discussion in Hacker News, if you want to take a look.