Technology Apr 18, 2026 · 9 min read

I tried Vim for 3 days and documented all my FAILS

When are you learning something, it's always a journey. It starts with unknown and slowly you figure more and more things out. In the beginning you have nothing to say - you desperately trying to understand anything. Then you figure stuff a little, so you can start sharing you experience. But here i...

DE
DEV Community
by Slava Shabalin
I tried Vim for 3 days and documented all my FAILS

When are you learning something, it's always a journey. It starts with unknown and slowly you figure more and more things out. In the beginning you have nothing to say - you desperately trying to understand anything. Then you figure stuff a little, so you can start sharing you experience. But here is the catch - most of all your insights coming from the experienced version of you. Once we got something, we tend to forget the feeling of not understanding it. So we rarely see live version of learning, more like retrospective one.

I was always curious about this process, but never actually tried to document it. It recently happened with me, while I was... playing Balatro. I struggled a bit at first (never played that kind of games) but then I figure it out to a decent level and thought: "Damn, it would be cool to re-watch my earlier games and react to dumb decisions I made". But you can't unlearn something, so I decided to maybe try to document process of learning some game sometimes in the future. But then wild opportunity appeared...

VIM (all capitalized)

Being frontend developer you are blessed/cursed with no necessity to learn Vim. Even if your are on Linux, you kinda just ignore it and nano your way out of any troubles. You painfully learn how to exit Vim and after that you decide that you never touch this stuff again. But then you gain some experience, become more matured and slowly Vim crawls into your life.

Firstly, you meet Church Of Vim - its adepts seems to abandon any other editing software. Even when on phone, writing simple texts to (let's imagine) friends they abandon built-in phone keyboard and instead install docker container inside of virtual machine inside Raspberry Pi with full-sized keyboard they carry in their pocket just to avoid writing something without Vim.

You think: "Well, I'm not lunatic to abandon my cozy VSCode (or its forks) with extensions and AI. Vim does nothing for frontend, so I will not bother".

Secondly, working as a frontend dev inevitably makes your scope much wider (no, it's not sexual metaphor). If you ever need to actually edit come configs on server, you use nano proudly at first, but then you hear that true programming magicians actually enjoy Vim, nano is for cats (or maybe they use another related word, not quite remember). So Vim gets to your ego: "Why other can master it, but I avoid it like plague (or startups with three mandatory daily calls)?".

Thirdly, you meet Vim-pushers. They are seducing you (not if a fun way) and trying to convince you: "Just try it, bro. You can even use it inside your VSCode, bro. It's otherworldly experience, bro. You never edited like that, bro". So you think: "Hmm, why not, why shouldn't actually try Vim".

And then you install Vim as a extension to you VSCode and journey begins.

Beginning of the end

So yeah, this exaggerated tale is about how I decided to learn Vim. And then I remembered - hey, it is really good opportunity to try this live learning thingy. Of course, I will not actually record myself, I'm not streamer/psycopath. But I'm gonna try to document this process with my actual thoughts.

It means that yes, I definitely gonna spill some bull-crap on how things work, do some things very inefficient on how things work. But that is the point - to show mind of the beginner, so I can return to it later and correct myself - both in details and mindset regarding working with this software.

Learning process

So, right now I have three days of actually using Vim. By using I mean I installed it inside my VSCode as an extension and currently trying to become familiar with it. I decided that using it for actual code would be little to much for now, so I took bunch of Markdown files (project docs, some personal guides) and try to mess with them.

Radically practical approach

While I met some amazing tools/guide for learning Vim, I decided to try dive head first inside my actual work experience. So I went to Deepseek and briefed it like this:

I'm gonna try to do my actual work with Vim, which is unfamiliar for me. When something will go wrong, I will run to you in tears and you will say to me that I'm the best human you ever met (and also will fix my mistakes and explain them to me, but this comes second).

So, I began my learning journey.

Mindset

I knew that idea already, but now I have to actually understand - Vim is not for writing... it is for writing AND editing. This is two separate processes, that you switch on and off. So it is why there are actual two modes:

  • insert mode - is where actual writing is done

  • normal mode - is where editing is done

At first it actually seems batshit insane - regular editor is a tool that allows me to do both simultaneously, why should I change it to software that have this modes separated?

Since I have limited experience now, everything is still slow so I can't report with massive productivity gains. But I can report on vibes. For some reason (and it's purely personal feeling), it seems kinda right to have it in two modes. You not trying to do two things at once, you switch between two states. It is surprisingly beneficial for flow of my mind.

Basic commands:

  • esc - to go from insert to normal
  • i - to go from normal to insert, placing cursor before selected letter (a is also make the same switch, but putting cursor after)

So I have to sit and switch between modes over and over, but it is still not even close to muscle memory (for some reason, I sometimes press Caps Lock, which changes language on my machine).

Major bummer

I have a very strong muscle memory for switching tabs - Ctrl + PageUp/PageDown is happens instinctively.

Surprise, surprise - Vim doesn't jive with this shortcut very well. When using Vim extension in VSCode this combination does nothing, so I have to re-learn myself.

What Vim actually uses:

  • gt - to move to next tab
  • gT - to move to previous tab (this seems very inconvenient for me, since it requires usage of Shift for capitalization, but maybe I'll get the hang of it)

Oh, and CTRL + W (closing tab) is gone too, this substituted with :q.

Not good, not terrible

Also, good ol' undo/redo is also gone. Vim wants you to actually use:

  • u - to undo (which is very intuitive, I like it)
  • CTRL + R - to redo (which is okay).

VSCode still allows me to redo as I'm used to, but actually using one button seems kinda cool to me.

Very confusing

I knew that Vim is very special in how it is copying text and always was a little bit afraid of it. Turns out it was not so bad:

  • yy - to copy line
  • p - to paste thing you copied

both are fine too. For some reason it required new word YANK ("Judge, actually, I didn't copy-pasted this proprietary code, I yanked-pasted it, which is totally different. Maybe, you can let me go?").

But when you want to copy something and move it outside of the app, it gets quirkier. To copy line into clipboard, I had to:

  • "*yy - for copying
  • "*p - for pasting

If you are paying slightest bit of attention to this rambling (aka post), you can notice that it is the same commands, prefaced with some magical symbols. What do they actually mean:

  • " - use specific register (as I understood, like specific clipboard)
  • * - the name of register (* - is system clipboard in my case)

Maybe I will also get used to it (or find better ways), but for now - it is extremely difficult to use.

Kinda cool

What I actually liked so far is removing text. Removing multiple lines, removing words and remove text in specific circumstances.

Logic goes as follows. You have d to actually remove stuff and then some modificators to make deletion special:

  • dd - removes current line
  • dw - removes word
  • d$ - removes everything from cursor to the end of line
  • d} - removes till the end of paragraph

And this command is the part where I see Vim's actual power. Flexibility of this tool seems to be very convenient.

Also, all of these commands are seems to be modular. So you quickly get a grip on logic here - if d$ is removes text from cursor to then end of line, y$ - must do the same for yanking. More over $ itself places cursor to the end of line.

This modularity seems rather cool too. Obviously, I'm nowhere near actually using it fast, but I can see that it can be very handy and flexible.

Navigating is... different

What also messed with me is that you can't jump from beginning of one line to the end of previous line by pressing left. For Normal mode it seems not so big deal (there are plenty of instruments for navigating), but the absence of it in the Insert mode messed up my vibe a little. We'll see how I will adapt to that, I guess.

As to moving cursor in Normal mode:

  • $ - jump to the end of the line (already mentioned it)
  • 0 - jump to beginning of the line
  • h - left
  • l - right (using l for right seems - some good plot-twist here)
  • j - down
  • k - up

These commands seems nice to use. It feels very fast, despite I'm being not good at it.

Conclusion

So, yeah this is the actual experience of the beginner. I tried Vim for a couple of days for my work - end of story. Right now it seems like a deranged micro-guide, but I hope this article will be cool to review, once I return to it later. Or maybe it will motivate you to try it, bro. Or remind you of good ol' days you learned Vim in 1993. But for now, that's what three day of not very intensive practice will get ya.

Thank you for reading.

DE
Source

This article was originally published by DEV Community and written by Slava Shabalin.

Read original article on DEV Community
Back to Discover

Reading List