Why I Learned Vim
A brief look at my history and how ordinary jobs lead to learning programming and Vim/Neovim
Something I see pretty consistently when the topic of Vim/Neovim comes up is the inevitable question “Why?” Thanks to years of memes about not being able to quit Vim, it has gained a cult popularity of being “elite,” “ancient,” or both. Most developers who are comfortable in their VSCode environment can’t imagine using something so unfriendly and perhaps ugly. So yeah, “why” is a fair question. I reflected on that question and I realized how my own life experience led me to learn Vim, and perhaps it would be helpful to share that story.
To understand why I use Vim, we gotta go back to 2013. I just graduated college, and I needed a job. I got one at Bass Pro Shops as a footwear associate. It was a pretty standard retail job, I would fetch shoes from the back as people requested sizes, organize displays, and unload freight. Starting out, I was an “ok” employee, but thanks to my boss Chuck, that changed. Early on he would half joke “oh you’re finally done?” or “it’s about time.” It was strange combination of mocking and encouragement, hinting that I was not meeting my full potential. It spurred me to do better, to work smarter and faster. Chuck not only gave me a strong work ethic, he gave me the desire to be productive. Even in that footwear position I learned how I could be fast, accurate, and highly productive in ways that other people noticed.
I worked up the ranks and eventually became a manager of the hunting department, doing stuff I never thought I would, like doing inventory stock requests and other computer-heavy tasks. I’m not sure about retail stores, but this one used an IBM system to handle their internal inventory and product info. It was the classic black screen with green text; all keyboard, no mouse. Here I learned to be fast thanks to keyboard shortcuts. I was able to apply what I had already learned, that fast and accurate resulted in productivity, to machines.
Of course, my time in retail was limited. It’s a hard job to sustain and justify over a long period of time, and I wanted something more regular. I heard banking was a good transition from retail, so I got a position as a teller at a local bank. Just like retail, banks work with data. A lot of data. From day one I had to learn how to use their software to access all that data, and it was not the best experience at first. We used a web GUI nicknamed “white screen” where you had to do a whole bunch of clicking to navigate or get access to anything. It wasn’t the keyboard speed I was used to at my previous job. I found ways to get sort of fast, but nothing amazing.
Then one day, a coworker showed me “black screen.” It was the exact same access to the data but through the familiar IBM style terminal UI, all driven by keyboard with no mouse! I was ecstatic, and quickly learned to master it. I was fast again, boosting productivity at incredible rates. I could pull up anything in a few key strokes faster than anyone. I loved it. Once again the hard work ethic and productivity paid off, and I climbed through the ranks of the bank and later became a manager in a back office support role. Through my speed and accuracy, I became the guy who knew a lot and was infamous for getting stuff done.
Several years go by in that role and it started to take its toll on my mental health. It was 2020, my first son was just born, and while waiting in the car for my wife finish to a doctor’s appointment (no plus ones back then), I stumbled upon the opportunity of programming via YouTube. I wanted a career change, and programming sounded interesting. After just one weekend of deep diving into web development basics, I was hooked. This began my journey of becoming a self-taught developer, which you can read more about here. It was a rough but exciting time, as I would wake up early to learn and write code, go to work, help out my wife with our new son, then stay up late into the night to keep going.
After a few months I was making pretty basic websites, using the ever popular editor VSCode. Even then I was prioritizing how I could be more productive by taking typing tests and working on improving my WPM. It was logical to see that being able to type faster would result in higher productivity in both writing code and just writing in general. However, it was around that time I saw a video about Vim from none other than The Primeagen. Immediately I was blown away by the speed, and I knew I had to learn it. This was the next level of using the keyboard and special shortcuts to achieve the speeds I craved. I started with the classic Vim Tutor, slowly learning the keybindings and exploring the config options.
That was about three years ago, and I had the advantage of learning Vim early on and it becoming a standard part of my workflow. Plus it was on my own pace; I was not programming professionally at the time so it’s not like I had to go through a period of not being able to push out code for a job. Nevertheless, I am so glad I took the time then to push through it. To this day Vim keybindings and Neovim have helped me become more productive and write code faster.
Perhaps a question you might be asking yourself now is “should I learn Vim?” Honestly the answer might depend. I would say there needs to be an important distinction between Vim keybindings and Vim/Neovim itself. AKA “Vim Motions”, allow you to manipulate and “edit” text. You can write text in pretty much any application, but true editing lets you maneuver and mutate text in ways you never thought were possible. The keybindings are used in other applications including VSCode with the Vim extension, and in my opinion they are worth learning. You can at the very least toggle between them and practice them, and can help you if you ever find yourself on a server and need to edit a config file quickly.
Neovim as a text editor is a different story, because at that point you are setting up your dev environment on a personal and custom level. The UI and features that you would see at startup in VSCode will likely not exist at all, and would require plugins to recreate pieces of functionality. Some might see this as a downside, however it gives you the opportunity to make something that works for you and won’t slow you down. Taking the reverse route in VSCode by removing UI elements is much more difficult in my opinion as I have tried it, and it just isn’t the same. Nothing beats a Neovim configuration specially built to handle the code you need to write.
Is Vim worth learning? Perhaps a better question would be “how fast and productive do you want to be?” If you’re like me where you have an itch that can’t be scratched, always finding ways to automate, speed up, and maximize productivity, then you may want to consider trying it out. It does take time to learn, and it could initially hamper your productivity, but at least you gave it a shot. For others Vim is not the answer, and VSCode is actually what makes them more productive, but you never know until you try.
My personal advice for those wanting to dip their toes into Vim would be using the Vim extension in VSCode. Try to use it as much as possible, grind through the pain, watch these videos to learn the keybindings and movements, and just push yourself to the max. It could take weeks or months to start feeling the results, but once you do, it’s hard to go back. When you feel pretty comfortable then you should try working in Neovim from the terminal and start building your configuration. There are plenty of distros that can give you a head start, but arguably the best is kickstart as it teaches you how to build your config instead of handing you too much. Getting a solid config will help your speed too as it will help you access files faster, switch projects, handle git, and more.
The goal of this post is not to convince you that you should learn Vim, but show you why I personally use it and why I think thousands of other developers enjoy it as well. In the end you should use what works best for you, but also keep an open mind to the possibilities.