A warning from a Vim user

At the beginning of every programmer’s journey, one is faced with a seemingly simple but unexpectedly complex question: what text editor or IDE should I use?

I hope I’m not the only one out there who has had near existential crises on this topic, but I’ll be the first to admit that it’s true. It’s a general software engineering rule to always pick the right tool for the job, but a text editor isn’t that simple. A quick google search of “what text editor should I use”, reveals a plethora of options for different use cases, with a few distinctly compelling contenders. These include large IDEs which are often overwhelmingly packed with features but feature rich nonetheless, and lightweight text editors with too few features to make a compelling argument as a full time editor. I won’t elaborate much on this, but suffice it to say there are many options.

And then at the bottom of this list is usually Vim. Such editors are a different beast, and promise a very high level of efficiency, at the cost of being difficult to learn. These promises are generally true, and at least in my personal experience, I was able to return to my normal level of editing speed after a few days, and as of writing this am quite capable with configuring and using Vim for my day to day programming tasks.

But why? This article is not at all trying to convince programmers to switch to Vim, but to notice the reasons driving our decisions. While choosing to use Vim, I can promise there was a small voice in the back of my head saying “well, it’s the hardest to use, and smart people on the internet say it’s the best, so why not!”. This is the same line of thinking that made me switch from Ubuntu to Arch Linux, to use tmux without a genuine reason, and to write programs in C when Python might be just fine. There is nothing wrong with Vim, and a lot of the advertised benefits are true, but it’s important to realize the driving factors to switch from one tool to another.

I’m trying to point out the susceptibility of using a tool for an ego boost or as a justification to procrastinate instead of doing actual work. For me, I truly enjoy tinkering with new tools, and have learned a lot through tech rabbit holes trying out new software even when they were possibly not useful. I can promise that I’ve spent way too much time in man pages and READMEs telling myself that I was learning the best tools and that would result in the best product or better productivity.

Just as trying to apply your particular skill set to an arbitrary use case may result in a less than ideal software stack or development environment, constantly learning “the best" can result in tunnel vision which will drive us crazy and prevent us from getting real work done. I don’t regret learning vim, because it taught me to be more careful when diving into a new tool. That being said, I openly acknowledge the hours I’ve spent learning a text editor that could have been used towards building things.

At the end of the day, I’m more productive and am happy with my development environment the way it is. However, I can honestly say the effort to get to this point was exorbitant, and sometimes I’m not sure whether I would have been better off just learning VSCode and the powerful features it offers. In general though, when learning something new, it’s a good idea to evaluate the potential effort required versus the potential output it will generate. In this particular case, Vim had a very high level of effort required to master, but only increased my productivity a little bit. Sure, I enjoy that little extra added productivity, but I have a hard time justifying all the time I sunk into getting to this point.

In a world where the software landscape changes every few years, with new frameworks, languages, text editors, anything, it’s important to build this skill. The skill to recognize the benefits and drawbacks of different choices, and most importantly to take advantage of them. Learning is fun, but regardless of discipline, what matters is how we use our tools to do our job. So get out there, learn a few new tools, but please see the bigger picture and make something amazing with your skills.

I'm a software engineer who is passionate about programming, playing guitar, and fitness. That's pretty much it.