Or why I switched away from Vim.
Getting into Vim
At my first internship, my mentor scolded me for using RubyMine to edit a Ruby on Rails project, claiming it was too enterprisey and that Real Programmers™️️ use Vim and live in the terminal, but the lesson stopped there. I slowly tried to use Linux more and more, but as can be seen on this blog, my first several attempts didn't go well. But I did learn some things and I did learn some basic things about Vim (at least I knew how to exit it 🙃).
Then at my first job, my team lead, Sever, knew Vim really well and pretty much lived only in the terminal. Because I pair programmed a lot with him, I learned a lot. He took the time to explain to me some useful settings and plugins. He even showed me Gundo (to visualize the undo trees), but I have to admit I never used it since.
Under Sever's tutoring, I got hooked on Vim. I started customizing it, adding plugins to it. I memorized a lot of commands and I became pretty proficient. I read blog posts about it and looked up to Tim Pope, who had written lots of great plugins for Vim. I even started evangelizing it to other colleagues, saying how awesome it is, how great the action composition model is and so on. I had
YouCompleteMe for autocompletion,
vim.vinegar for file browsing, and about 20 other plugins. My
.vimrc file eventually grew to over 250 lines.
Then I went to work at Google. At first I was working in Python and later in Go, and I kept using Vim. Because there were some Google-specific vim plugins, I had to split up my configuration, to have some parts which are common and some parts which are home/work specific only. This meant that keeping things was more difficult.
Vim falls into disuse
But then I switched to another team and I started coding only in Java. I discovered that Java can be pretty nice, if the code is not overengineered like I learned in college. But still, Java has a lot of boilerplate code, so using an IDE is a must. At least back then (4 years ago), there were many features in IntelliJ that you couldn't replicate in Vim, such as accurate and always up to date "click to go to definition" or semantic renaming of variables.
During this time my
.vimrc didn't get much love. I would still use Vim whenever I would code something at home, but that was not too often. And every now and then, something would break. Usually
YCM, because the
clang would get updated and
YCM would fall behind. Some things I could fix, some I couldn't figure out in less than an hour, after which I would give up.
After I had left Google, I started working in Python again, but this time I went pretty quickly for PyCharm, which offers almost exactly the same features as IntelliJ, but for Python. Very similar UI, the same keyboard shortcuts, the same workflow.
But I often had to SSH into other machines, some of which are random production machines and I would have to edit some files there. Of course, I would reach for Vim. But I wouldn't have my configuration with me. So I would try to use some shortcuts and they wouldn't work. The one that still bites me to this very day is using
- to open the file browser if in a file, or to go to the parent folder if in the file browser. I think this command is enabled by
vim.vinegar. So I would become frustrated that I cannot edit using my regular workflow.
Today the Vim ecosystem has improved a lot. There's Neovim which adds lots of fancy new features. There are new UI wrappers for Vim. There's a much more powerful plugin system which enable things you couldn't do before. If I really wanted to, I could probably replicate everything I need from PyCharm in Vim. But is that the best use of my time?
I don't think so. First of all, my experience lately has shown me that I often have to work with default Vim instances, so I would have to remember to sets of commands, one in my customized setup and one in default instances. Theoretically I could set up a script that would copy my
.rc files to the remote computer every time I ssh, but I don't want to leave a mess behind me on every random cloud VM that I log in to.
Second of all, I don't think spending that much time on customizing Vim and memorizing keyboard shortcuts is going to make me that much more productive. I find that as a team lead, I don't spend as much time writing code. Luckily I don't spend too much time in meetings, but I do have almost every day at least 1:1 call with someone from my team to discuss how to proceed on some feature. I also spend a lot of time designing microservices and thinking about scaling and consistency issues. And when coding, I don't find that my ability to churn out code is a bottleneck, rather, but my ability to think about the interactions of the various microservices involved and how the data flow can go wrong in one way or the other. So I think investing in better tools for thought has a much better ROI for me.
Do I still like Vim? Of course. Do I still use it when I have to quickly open up some files in the terminal? Absolutely. Will I invest hours into learning more about it and customizing it more? Nope.
I’m publishing this as part of 100 Days To Offload - Day 4.