Listening to Piero Piccioni's Le altre soundtrack while writing this.
Learning Vim transformed my ability to perform as a software engineer in more ways than I ever expected. Not because of the speed. Because of what it took to get there.
The First Encounter
In college I had loosely heard of an older way to code. It was faster, but notoriously hard. I would read people joking on internet forums about how they struggled to exit the code editor. When I tried, I of course, didn't know how to exit like everyone else. It seemed foreign to me, and made me question why someone would bother to learn such a "coded" way of developing when they can just use a souped-up IDE like everyone else.
I quickly removed it from my computer, let it be a memory, and moved on with life. I graduated, got my first job, and spent my first few years learning what it means to be a software developer. Talking to stakeholders, setting deadlines, meeting those deadlines, working my way up from junior to officially a software developer at a top 50 financial firm.
Coming Back
After some years of work under my fingers, a memory of Vim came back to me while browsing the internet. I learned I could actually use Vim motions inside my existing IDE, the safe one I had already spent years getting used to. I read about other developers swearing by Vim, Emacs, and more modern takes like Neovim. I was looking for something "big" to chew on. Something that could keep with me forever and have a lasting impact on my ability to work effectively.
I found a slow stretch during Christmas. Stakeholders were with their families, half my team was offline, deadlines had shifted out. I decided to just start. I locked myself into only using Vim motions at work and committed to using Neovim on my personal projects.
Pains of the Learning Curve
I struggled. But I persisted. After the first week I was somewhat functional, quicker than I thought. After the first month I was moving. Messing up some strokes, doing things a little slow, but finally getting faster than reaching for a mouse.
My coworkers saw it too. I hadn't figured out that Vim's yank doesn't copy to your system clipboard by default, so anytime I needed to paste something into a browser or look something up in GitLab, I would have to right click and copy like anyone else, or just retype it by hand. During a screen share, my senior coworker watched me do this and asked, very bluntly, "You don't have copy paste set up in your code editor?" I couldn't help but blush. Grateful our cameras were off, I stumbled through something about it being a new setup. I laugh about it now.
For those curious, the setting was vim.opt.clipboard = 'unnamedplus'.
But that's what the learning curve actually looks like. It's small embarrassments and stubborn persistence until things start to click. And they did click. Something shifted in how coding felt. I felt tactile with my code, like I could mold and morph what I was writing as if it were a physical item in my hands instead of virtual text on a screen. It was genuinely a different feeling that I learned to love with time.
Making It Mine
My setup felt like it was finally mine when I read through the codebase of a plugin I was using and used it as a reference to write my own. A Lua plugin that let me hotkey up to 10 terminals on my keyboard, plus a quick chat window to an LLM agent using my own API keys. So essentially I could spin up 10 independent AI agents alongside a quick window for small questions, all accessible from the keyboard.
The setup felt unreal. I could navigate my terminals, jump into Lazygit for quick and precise git work, hop between different LLM agents as I moved through my codebases using oil.nvim, all working at the same time as my own editing and planning speed. No mouse. This is the comfort and efficiency I was looking for.
The Real Lesson
The thing Vim actually taught me wasn't Vim. It was that throwing yourself into the unknown and surviving it changes what you're willing to try next. It puts into perspective what you are capable of and what you can learn from as a result.
I started as the backend developer on a new project at work. But when production React bugs came up in an app only a fraction of devs knew how to work in, I was the one who went out of my way to fix them. This was before AI tooling and AI agents were a thing. I'm not sure I would have volunteered so readily before having thrown myself into my own unknown and seen myself come out better because of it.
That same willingness is what led me to pick up HTMX for GameScrape instead of reaching for what I already knew. It's what gave me the confidence to set up apps on AKS, configure PaaS deployments on Divio, and learn React on a dime to fix codebases that were hard to work in. Each time the pattern was the same: something unfamiliar, the instinct to avoid it, and then the memory of what happened when I didn't avoid Vim.
Developers tell me how much faster they are because of AI agents and LLM tools. I get it. I use them too. I literally built agent tooling into my Neovim setup. But if I'm being honest, what made me a genuinely better and faster developer is the work I put into learning Vim. Not just because I can refactor and navigate codebases faster than most people can read a line of code, but because of what lives underneath that.
The real speed came from the discomfort. The toiling. The investment in myself. AI tools can generate code, but they can't give you the instinct that comes from having struggled through something hard on your own terms. That's the thing that compounds. The courage to venture into the unknown and the confidence that comes from knowing you've done it before is what made me the engineer I am today. The tooling just followed.