Author’s note: the names have all changed, the stories are real. I use the term “Vim” throughout the essay to refer to both “Vim” and “Neovim”.

A cigarette dangled precariously on the edge of Ron’s lower lip. A moment of repose before another machine gun flurry of keystrokes. Change line, type, rename function, move function closure to end of page, jump to top of page, open imported file, search by pattern, replace all instances of function name, search across all open files for an element’s ID. Another pause after this volley, hand reaches up to grab cigarette, a sip of coffee, “Basically like that, make sense?” I lied and said “yes” Ron just exercised a bug out of the codebase with the speed and precision of a neurosurgeon, if that neurosurgeon had consumed near-lethal quantities of amphetamines.

I met Ron while I was working a remote software gig. He had a lot of years in the game and was exquisitely particular about his tools. His tool selection was part of his thought process, his way of working, his way of approaching interaction with a computer. By that point I had seen a lot of different coding methodologies replete with their own tools and idiosyncrasies. What I hadn’t seen much of was someone getting into a flow while coding. Whenever I saw Ron code, he would consider the problem, think for quite a while, then put his hands to the keyboard for quite some time, changing and navigating through the codebase with a strange combination of laser focus and total ease. The way Ron though was modal, he flipped through modes of talking, thinking, and coding. These switches were slow - he stayed in one mode for a while which seemed to gain some efficiency. Modification operations would be done in batches while he was in his mental modification mode, thinking operations, the same. Some of these modes mimicked the modes of the editor but it was clear that this metaprocess transcended a 1:1 link with Vim’s functionality.

“First we shape our tools, and thereafter our tools shape us.” - Marhsall McLuhan

Whether Ron worked in a modal way then found a tool that fit into his working style or started using a modal editor then began working in a modal way is irrelevant at some point, for better or worse, usually worse, tool and thought pattern converge. I have made this point dozens of time in my academic and casual writing, where this differs though is that the tool, Vim, is infinitely malleable for any working style. Vim isn’t the only tool that can claim this amount of adaptability, however what’s strange is that all three of the most prolific coders (note: not necessarily engineers) who I have met in my career have not only used Vim but adapted to radically different working styles that suited them specifically. Either one of these components, a specialized tool reflecting someone’s specialized way of working, and a highly customizeable tool are somewhat unique on their own but extraordinarily improbable in combination.

Jamie

Jamie had a medical issue that affected his hands. If he worked too furiously at the computer, he’d loose feeling in his hands and could even suffer nerve damage. On the occasions he did still program he sat with perfect posture at the keyboard moving his hands by just by a millimeter or two to produce the keystrokes necessary to edit code. At that point, I had never seen anyone use Vim before, didn’t even know what it was. As I learned more and tried my own hand at learning (the first of many times I would make the attempt), I realized that my Vim was nothing like Jamie’s. Some of the key combinations were the same but most of them weren’t. Jamie had extensively remapped default keybinds in his Vim configuration and employed a special keyboard and footswitch array that ensured his hands never left their optimal ergonomic position on the keyboard. He even used a more ergonomic keyboard layout called “Dvorak” which aims to require less finger motion and reduce the risk of strain. If Ron’s interaction with Vim was powerful and bombastic, Jamie’s was nearly telepathic.

Configuration

Many editors are configurable. VSCode is highly configurable. Where Vim differs is that useful things are easy to configure, the rest is difficult - this punish/reward mechanism makes up much of what is unique about Vim and those that use it; not only the use of the tool, but its configuration implies a certain way of working and thinking. Vim is exceptional in that it allows for easy configuration of things that should be configurable, stupid things are hard to use and hard to customize in Vim.

Of course, just because something is stupid and hard to do, it doesn’t stop people from trying. An entire community has sprung up around Vim with the intent of trying to recreate VSCode inside of the terminal. Such idiocy surpasses my understanding. I have sampled two of these prebuilt configurations - NvChad and Astro Nvim, both of which create an entire mouse-compatible GUI in the terminal. If you have a workflow that is more compatible with VSCode, simply use VSCode instead of reinventing it in the terminal. My hunch is that many of the regular posters on Reddit’s /r/neovim board spend more time updating configuration files and implementing VSCode functionality in Vim than they do using the editor to create things or earn money. It seems a lot like when someone buys a high performance car, works on it and polishes it obsessively, then takes it out once a month for a car show. It’s always been my take that it’d be more fun to drive it and not worry so much about scratching it up. That’s a bit what Vim feels like to me as someone that’s relatively new to using it as my default text editor. It feels fun and engaging. I find myself thinking and moving more intentionally when programming in Vim. It’s a lot like when I learned to drive a standard transmission for the first time - is it faster than driving an automatic? Not necessarily but it forces my brain to stay engaged and not zone out which, once you get good, can feel fun. I have not gotten good at Vim yet but sometimes I land a few key combinations in succession that accomplish something that would be pretty fiddly with a mouse and I get a little glimpse at what Ron was talking about all those years ago when he asked, “make sense?”

Third Man

Keen readers will note that I mentioned three coders near the beginning of the article. I have omitted an anecdote about the third because I currently work with them and didn’t want to threaten their anonymnity. They are a legendary Vim user and I’m proud to work with them.