This article was originally posted on March 19th 2019 at: https://nickjanetakis.com/blog/getting-productive-with-vim-in-a-week-without-hating-it
I'm hardly an expert with Vim as I've only been using it for a little over a month.
But I found myself being quite productive with it after about a week and it's only gotten better since then. I think it's worth writing posts like this while you're still a semi-beginner because once you've been using something for a really long time, it's easy to forget the details of what helped you out early on.
With that said, this article is more about my personal journey on how I approached learning Vim rather than being a step by step tutorial. Although, by the end of this article you may have picked up a few tips to help get yourself up to speed with Vim quickly.
Diving into It with No Safety Net
I usually learn best when I'm fully immersed with whatever I'm learning. I still remember learning Rails 5+ years ago in about 3 months while I built my own blog platform while watching a ton of Railscasts videos to learn Rails as I went.
Before I started that 3 month adventure I had no Ruby experience, but by the end of it I had learned enough to comfortably start taking on new Rails based freelance gigs. Although it's worth mentioning I had 15 years of general development experience coming into it, so a lot of general web dev concepts were already known to me.
So when it came to learning Vim, I kind of did the same thing. Once I knew I was 100% done with VSCode (I stopped using it due to how bad it performed with 1.5MB markdown files I uninstalled it and Vim became my go to editor.
That means when I was doing freelance work for clients or writing my own course content, I willingly took an initial productivity hit but I went into it knowing full well that I was going to be much less efficient for a while.
The First Weekend
I normally don't do contract work on the weekend, so I decided Friday night that when I wake up the next morning, I'm going to go at Vim hard until Sunday night.
With no real prior Vim knowledge (I looked at it once many years ago) it took a solid weekend to go from overwhelmed to sort of happy with the switch.
And when I say solid, I mean I spent 10 hours both days researching Vim features, watching tutorials, following along with tutorials and slowly introducing a couple of plugins I knew I wanted (based on exact problems I had).
A lot of this time was still spent in the "omg shiny" phase where I was watching a ton of Youtube talks about how useful Vim is. I don't care what anyone says, that initial hype phase is important because it sets you up with incredible motivation.
After the hype, it was time to make a config file:
Once I felt like I was going to take over the world I really got into configuring Vim.
I knew writing my own .vimrc file from scratch was going to be too much because there's a million settings and twice as many unknowns. I had no idea what was possible or what I even wanted.
At the same time I knew I didn't want to start with some type of massive pre-made solution like SpaceVim. I have nothing against it and it might be amazing, but I know from personal experience that starting with a massive thing is going to make it much harder for me to understand what I'm doing. Abstractions come at the end, not at the start.
So I eventually found a basic .vimrc file gist and I used that to help get me going. As I went through the config I ran :help <setting> on every setting I saw.
I even made my own adjustments to some of his settings based on what the help had to say and I think that's an important thing to note. You have your own preferences and ideas on what's "good", so if you find something you like you shouldn't be afraid to make it your own.
You also shouldn't discount something entirely because you don't agree with it 100%. Chances are you can learn a lot about something even if you only agree with half of it.
Sunday night:
At this point I had a very bare bones config and a couple of plugins. During this process I didn't even go through vimtutor yet. My thought process was I wanted to get some type of sane environment working before I embarked on really learning Vim.
In hindsight that was probably not the best idea but I've always been the type of person who jumps into something and tries it out before reading a ton of manuals. Also during this process of making a config file I was actively using Vim, so I was getting "real world" experience.
I don't regret my decision in the end but I think if I started with vimtutor (which is a built in command if you install Vim) it might have been a little faster to get going.
Life with Vim after a Week
The next couple of days weren't easy. I spent a few days floundering around like an idiot while I hardcore failed to even do simple things like "move to the 2nd to last word in a sentence and then wrap the last 2 words to a new line". Doing that without arrow keys and no mouse almost killed me initially.
Even copy / pasting was a monumental task. It took me quite a while before I could copy text out of Vim into another application and paste text from another application into Vim.
This mainly stemmed from not understanding how registers work in Vim and also things being a little more tricky from the beginning because I'm running Windows 10, but I have terminal Vim installed inside of WSL. Lots of clipboard variables at play.
In general I kept running into situations that seemed so easy to do with other editors but were insanely difficult with Vim. It almost got to the point where I was like "fuck it, this isn't worth it" because it felt like I was getting hung up on so many things.
Even things as basic as pasting text into the exact spot of where I want it relative to my cursor. It took me almost an entire week to get used to how the block cursor works.
It's Not All or Nothing, Forget the Purists
I kept reading about how you should unbind your arrow keys and every single edit you make should be cleanly separated from movement. Also using the mouse is evil!
I did that for days and even tweeted about it:
But it was too much for my simple mind to comprehend. I've never been a home row typist and I never will be. My hands fly everywhere when I type but I'm somehow able to type at about 75 WPM with very high accuracy.
I also use the mouse a lot too.
Using hjkl for movement just isn't for me. I'm so much happier and faster by using the arrow keys in insert mode when all I want to do is move over a couple of characters.
Now don't get me wrong. I do use hjkl once in a while, but it really depends on what I'm doing which leads into another really big takeaway that I came to realize.
Not Every Movement Is a Black and White Decision
It took about a week to realize that but once I did, it changed everything for the better and I started to see real progress.
I was stuck in this mindset that I absolutely must do certain things in one specific way. For example, I was internally struggling with jumping to specific areas of a file that are in view.
I kept reading about how Vim is more than just insert mode and to really take advantage of it, you should leverage motions and hot keys to move around. You shouldn't hit the down arrow or j 10 times to move down 10 lines and then move over 15 characters to get to the point you want. That's very inefficient.
So then I made the mistake of going on a quest to find the most optimal way to move around the visible areas of a file. This lead to using plugins like vim-sneak, easymotion and measuring efficiency based on the least amount of keystrokes to move around.
That was a big mistake but I'm glad I went through that period. It was a reminder of what not to do. In various forms in the past I've written about how you're not going to find good solutions by trying to theory craft them, but that's exactly what I was doing here with Vim.
I was trying to optimize a solution to a problem I didn't fully understand.
Once I realized what I was doing, I immediately stopped and just focused on using / to quickly move to specific areas of a file. I found the context switch of using easymotion to be a lot worse than just naturally typing out a piece of the word I wanted to jump to.
But then I learned about f, F, t, T and % which are great for moving around a specific line. It solves a different problem than what / does in a very nice way.
The more I experimented with this, the more I realized that moving around and editing a file is an organic process. Sometimes I use the arrow keys, sometimes I use j to move down a line, sometimes I use the mouse and sometimes I'll use something else. It really comes down to the task at hand and what feels natural.
Sticky Notes Helped Build Momentum
It's worth pointing out through out the week I was adding sticky notes around my monitor that had common Vim commands, motions and mappings. By the end of my sticky note phase I had 7 of them with roughly 80 things jotted down.
The 7th one is still a work in progress on the top shelf and yes I use that Rubik's cube to block my web cam but it's also what I stand it on when I am actively using the web cam.
The sticky notes really helped build confidence and momentum because if I forgot something it was just a quick glance away instead of having to break my flow and Google it.
So if you find yourself looking something up more than once, write it down. It's worth it.
Getting Familiar with Vim during Week 2
By the second week I was starting to get the hang of things. I found myself naturally using motions like ciw, gg, G and . all the time and sometimes I was doing it without thinking which felt magical.
I was also using i, I, a, A, o and O very frequently. It still wasn't automatic to use all of them without thinking but I could see things starting to come together. I was now moving around and editing files faster than any editor I ever used in the past.
It was like Vim was an extension of my brain, which I never felt with any editor.
The real overall speed improvement came from only semi-memorizing 20 or so motions and commands. Each of them alone isn't a world changing event but when you combine them together, it really starts to add up.
And that's really a testament to the whole Vim mindset. With VSCode, I just saw it as yet another text editor. Sure after a year of using it I had a bunch of hot keys memorized but I never felt like I was getting that much faster with it.
On the other hand with Vim I feel like it's naturally pushing me to improve.
Vim Is Comparable to a Video Game
I'm a huge fan of video games and I tend to gravitate towards competitive games that have a high skill ceiling like Quake 3 or mobas such as Dota. When using Vim, I get the same vibe from it as I do when playing a game. I feel like I'm never going to outgrow Vim and it's actually really fun using it.
It fits a weird need in my brain to play games without playing a game. I also feel a sense of progress as I get better using it. It's like I'm leveling up.
Beyond Week 2 with Vim
At this point my vimrc was a total disaster zone. All it took were a few weeks of throwing things in the file and trying out a bunch of plugins until it got out of control. It was an unorganized 500 line monstrosity.
But at this point I was getting comfortable with what I was and wasn't using, so I spent a solid 3 hours one weekend going through my config. I removed everything I didn't want and organized things as nicely as I could. It's now in my dotfiles repo (screenshot included).
This is also when I started to add in a few custom binds, but the critical thing here is I didn't add them for the sake of adding them. All of the binds came out of a direct need. Basically if I found myself repeating something many times, I turned it into a bind.
Sometimes the binds didn't last more than a few hours, while others will probably end up in my config file forever.
The same thought process was used for plugins too. I didn't even search for any posts like "best Vim plugins". I only searched for a plugin when I came up against a specific problem such as "syntax highlighting for Dockerfiles" or "visualizing unwanted white space".
A Month of Real World Usage
It's worth bringing up again that through out this whole process I was in the thick of it trying things out with Vim. Encountering problems and building up muscle memory to solve them.
It's also worth mentioning that this was about the time where I stopped using the sticky notes. I memorized 80%+ of the commonly used things after 3ish weeks of sheer repetition.
Editing YAML files, Markdown, Flask / Rails / Phoenix projects and the list goes on.
I really do think that this helped a lot. If I had kept VSCode around to do client work then this process would have taken a lot longer because I wouldn't have gained any real experience using it. I also would have lost that immersion effect.
Plus, that initial weekend was really the only time where I was dead locked on productivity and that was off the clock. Then it was a few days after that where I was definitely less productive but it wasn't like I wasted 2 hours out of an 8 hour day.
It was more like maybe 20 minutes while a bunch of tiny things added up and this only lasted a few days, so maybe I dropped an hour's worth of time and yes when I tracked my hours, I billed myself 1 hour less because that's the type of person I am.
Although truthfully I don't think it would have been morally wrong to bill that 1 hour because what happens in 6 months from now? If I'm able to finish my work 15 minutes faster should that mean I make less money? That doesn't make sense.
Or maybe 6 months from now I'll just raise my rates and then you'll see an article posted here with a title of "How I Made an Extra 10% per Hour from Learning Vim". Maybe haha.
As an aside this is why hourly billing can be bad sometimes, but in this case the contracts I were working on at the time were billed hourly due to their ongoing nature.
What Is Worth It?
You bet.
I feel like I invested about 25 hours up front which will help me over the next 5+ years.
I'm not sure if Vim is going to be for everyone and I gain nothing from anyone switching but since I record video courses I very often get people trying to match their development environment with mine.
So I always wince a bit inside when I switch around key tools because I know it's going to mean others may try to do the same, which may distract them from taking the course.
I just wanted to get this post out to let people know Vim isn't a mysterious crazy person's tool that only gray beards can use after a lifetime of struggle. If you happen to be interested, it's worth giving it a fair shot. It's a very approachable editor.
How long did it take for you to get used to Vim? Let me know below.
Top comments (20)
Nice feedback, thanks!
Maybe some day...
But I'm a bit disappointed: I was expecting a developer feedback of Vim usage, not just typewriting.
How to navigate through files in a given project?
How browse the code like you ctrl+click in IDE?
How to lint your code?
How to pretty-print?
How to refactor?
...
Maybe in a next article? :)
Thanks again for your post!
I use fzf and fzf.vim. It's like Ctrl+P in Sublime / VSCode but better (there's more ways to search your project than just by file name).
I also use nerdtree to occasionally explore a project when I just want to poke around or rename / create / remove files, but 99% of the time I'm using fzf with multiple split panes.
Everything is listed in my vimrc at github.com/nickjj/dotfiles.
I never used this feature in VSCode because it didn't work properly since I run my apps in Docker. VSCode isn't aware of code running in Docker yet (not in a way that's seamless at least).
Due to the same reasons as above I lint my code running the raw lint command, such as
flake8for Python andshellcheckfor Bash.This could be improved upon by creating custom key binds for each language to run that specific tool inside of an existing container. Basically, have 1 bind I can press that calls different commands depending on what language I'm editing.
But Vim does have plugins to lint your code on the fly and show visual warnings near the line number. I just don't use them personally (and didn't with VSCode either because it slowed typing down a lot).
What do you mean by that? Some type of auto-formatting tool? I never use these tools unless the language specifically supports it (such as Elixir and Go). It can be done with Vim plugins.
The same as I did with VSCode. Find / replace with case sensitivity. I find this process a lot easier with Vim since it has world class support for finding and changing text in a selection, a single file or multiple files.
With that said, there's also the concept of LSPs microsoft.github.io/language-serve... and Vim has multiple servers and clients for popular languages.
For example there's Ale github.com/w0rp/ale and coc github.com/neoclide/coc.nvim.
This is a fairly new technology but when it's all set up you'll be able to get really really good auto-complete, jump to definition, linting and other IDE-like functionality.
At some point I'll check those out, but right now between what I have along with snippets I find things very pleasant to use on a day to day basis.
I agree that Vim is mostly a text editor and not an IDE, so I can't figure out how a developer can be as productive with Vim as with an IDE.
I would love being able to develop a real project with Vim, but the few tries I gave to it with PHP or Go projects have failed. When it comes to refactoring, find-and-replace is not enough.
I know about LSP and most of the IDE are using them as Vim does, but IMO it's not enough to have an acceptable developer experience. Or maybe, as you said, it's a new technology and it's not ready to use.
I also know about fzf plugin, because I use SpaceVim, but I never really tried it.
What I saw from SpaceVim sounds very, very exciting, so maybe some day it will be working great.
I highly recommend getting used to fzf, but also using the commands listed here: github.com/junegunn/fzf.vim. It makes it so easy to open files and find things across multiple files, especially if you bind them to a key.
I don't know if spacevim sets up binds for fzf, but open Vim in a directory with your project, then type
:Filesand then start fuzzy typing for a file you want to open. Normally you would map:Filesto a key so it's only 1 key press away.Also for find / replace, there's a few shortcuts you can do to make it really easy to replace things in the selection, the whole file or multiple files. This isn't related to fzf.
Like, all you do is select a phrase, hit a hotkey to find all the spots where it's used, then hit another hot key to initialize a replace and start typing your replacement term. Some of these binds are in my vimrc.
That's a little out of scope for vim. There's a lot of plugins for getting an IDE like experience, but the whole point of vim is text edition, not running other tools. I'm a primarily a web developer and my config is heavily geared towards that. It's a per user thing.
I totally agree.
IMO, each developer should build its own IDE.
I use tmux along with vim to build a kind of custom IDE. But nevertheless, there are a bunch of things that you can only do in the editor itself: refactoring, syntax highlighting, jump-to-definition, debugging. I found plugins for many of the features I need, but refactoring is poor. Or maybe I need time to understand how it works, and time is always running out !
There's languages (Statically typed ones : Java, Kotlin,...) and projects (big and legacy) I'll totally use an IDE for. But a lot of things can be done with just a text editor. Plugins I used not related to vim customizations itself are for linting, autocompletion, snippets, git and running various other tools... My basics for a pluging is fast editing. Any other tasks, I switch to a better tool.
How browse the code like you ctrl+click in IDE?
andrew.stwrt.ca/posts/vim-ctags/
How to lint your code?
How to pretty-print?
github.com/w0rp/ale/
How to refactor?
I don't have much experience here to help with
I've never regretted learning vim/emacs. That said, I tend to use a "traditional" IDE (VS, VS Code, XCode) when programming.
Your "VIM is Comparable to a Video Game" comment caught my eye. I've been trying to slog through my Steam backlog and started playing "Epistory: Typing Chronicles". It's unusual in that it's a typing game, but also that you use JIFE for movement (i.e. instead of WASD). Makes me wish there was something like that for VIM. Someone recently posted here about games that are like programming, maybe that's why "gamification" is on my mind.
Hola, meet Vim Adventures.
First level had me for a minute, then I remembered the game is just VIM. So, tip: top far right land square, down over the water squares. Enjoy.
I should have guessed such a thing exists....
Another gamified Vim learner is PacVim
Get used to it? A few months.
Use it well? 20+ years, and counting.
My mentor literally SCREAMED at me when pair programming because I couldn't get the hang of yanking words quickly enough. This was after maybe 2 weeks of learning
vi, and only a few months after learning *nix.Nice post, I like how candid you were about your experience. 👍
Vimtutor over a few weekends got me productive enough with vim for me to switch over; the level of customizability and the power of modal text editing some things I just can't quite quit.
PacVim looks like it could be fun as well for a more gamified learning approach, but I've not tried it: github.com/jmoon018/PacVim.
Thanks for sharing!
Well written article, inspiring to read even if I already know and use gvim as your learning process shows both initial struggles followed by rewards, etc
I've been using gvim for more than 10 years now, created a reference guide (github.com/learnbyexample/vim_refe...) but these days, I don't think I'm using it to the best of my abilities.
Just a few features like search, search and replace, open new line, context editing (especially in markdown to replace text between backticks, quotes, brackets, etc), complete word using Ctrl+P, complete line using Ctrl+l, shortcut to insert markdown code block and that's about it I think. Never used plugins.
I make a point of trying to learn something new every day. For the first 5 years using vi, it was vi commands :) Serious point - as you explain nicely above, you can get started and be productive with a dozen or so commands, then spend years learning tricks to hone your experience. Emacs is similar, but I never did like multi-key pressing, YMMV.
As for tuning, I've pretty much stuck with the default .vimrc I get with Debian's packaged version, a couple of adjustments for expanding tabs to 4 spaces (so shoot me tab fans!) and that's it. Probably 'cause vim is pretty new compared to the 25 years using plain old vi, I like the syntax colouring most of the time, but I also turn it off now and then as it can be distracting, especially when it messes up.
Nice article!
Personally I find vim as really nice tool to edit text and code. But it can be rather tedious to use pure vim for programming in e.g. Java or C#. Especially when working on solutions created by some IDEs. That's why I really appreciated having a build in vim mode in IDEs e.g. form JetBrains like IDEA and PyCharm even Vim mode for VSCode.
Obviously it can be hard to tweak it like traditional vim but most of the things are set up out of the box and you can enjoy vim typing experience and when in insert mode even most of the IDE build-in shortcuts work as expected. So it's a win win :)
I initially made my own vimrc, but after a time found that I preferred the Ultimate Vimrc to anything I could create.
Use a 60% mechanical keyboard. That's the best way to wean you off those arrow keys.
How can you hate vim? :)