Let me paint you a picture.
It's a perfectly good Saturday afternoon. You had plans. Real plans. Maybe you were going to finish that side project, maybe finally write some tests (lol), or at the very least touch grass for twenty minutes.
Instead, you're 4 hours deep into your Neovim config, you've rewritten your keymaps.lua for the third time this month, your lazy.nvim plugin list has grown by six plugins you don't fully understand yet, and your repo—God help you—is named neovim-final-final.
Not neovim-config. Not dotfiles. neovim-final-final.
Because the one before it was final, and that was a lie, and you knew it was a lie when you named it, and you did it anyway.
Hi. My name is Josh, and I have a configuration problem. I'm not in recovery.
"Just Use VS Code" — A Eulogy
I did use VS Code. For a long time, actually. It's fine. It's great, even. It has extensions for everything, it works out of the box.
But at some point, something shifted. I'd be in the middle of coding and I'd think: this editor doesn't feel like mine. It felt like renting an apartment versus owning a house. Everything worked, but none of it was mine. I couldn't knock down a wall. I couldn't rewire the kitchen. The landlord (Microsoft) was always one update away from rearranging the furniture while I slept.
So I did what any completely normal, well-adjusted developer does.
I nuked it. Installed Neovim. And fell into a rabbit hole I haven't climbed out of since.
Credit where it's due: a big part of what pushed me over the edge was ThePrimeagen. If you've never watched him, he's a developer who moves through code so fast it looks illegal, and he does it all in Neovim. Watching him work made me feel like I was using a tricycle when I could be riding a motorcycle. He didn't just inspire me to switch editors — he inspired me to tinker. To care about the tools. To never just accept the defaults.
The First Config Is Always a Disaster (And That's the Point)
Here's what nobody tells you about switching to Neovim: the first week is a humbling experience.
Honestly, my first encounter with Vim wasn't even intentional. I made a git commit without the -m flag, and suddenly I was staring at a screen I did not ask for. I had no idea what it was. I just knew I was stuck. Couldn't type, couldn't exit, couldn't do anything. I literally Googled "stuck in commit can't exit" — not even "how to exit vim" — because I didn't even know it was Vim. That Stack Overflow question with 2 million views? I am one of those 2 million people.
And yet, somehow, that cursed moment planted a seed.
Fast forward to actually switching to Neovim full time: you forget how to save files. You accidentally enter some mode you've never seen before and the only way out is to close the terminal and pretend it never happened.
But then something clicks. You learn that every single thing—every keybind, every behavior, every color on your screen—is a choice you made. Nobody pre-packaged it for you. When your LSP starts working and Telescope fuzzy-finds a file in 0.1 seconds and your statusline shows exactly the info you care about and nothing else...
That feeling? That's ownership. That's craftsmanship. That's the closest thing a programmer gets to carving their name into something.
The Configs That Taught Me More Than Any Tutorial
Here's the dirty secret about tinkering with your dev environment: it's not actually about the tools.
Sure, I love my which-key setup. I love that I've bound <leader>\ to Telescope and <leader>gg to NeoGit and my fingers just know where to go without thinking. I love that my Neovim is fast—genuinely, disgustingly fast—in a way that VS Code on a good day can only dream about.
But what I actually learned from all of this:
- How Lua works, because your Neovim config is just a Lua program. You are literally programming your editor.
-
How LSPs work—like, actually work. What a language server protocol is, why it exists, what
mason.nvimis doing when it installs one. - How terminal multiplexing works, because once you go Neovim you inevitably end up in Tmux, splitting panes, managing sessions, and feeling like a wizard in a movie about hackers.
- How to read documentation, because Neovim will teach you patience or it will break you. There is no middle ground.
None of that came from a course. It came from breaking things, reading the source code of plugins at 1 AM, and occasionally nuking the whole config and starting over.
Which brings me to something important.
The Nuclear Option Is Not Failure. It's a Feature.
I've deleted my Neovim config and started from scratch multiple times.
Every time, I told myself this is the final one. Every time, I was wrong. Hence: neovim-final-final. (Spoiler: there will be a neovim-final-final-v2. I've made my peace with this.)
And you know what? Each restart made my config better. Because I stopped copying configurations I found online wholesale and started understanding why things were structured a certain way. I stopped installing plugins because some YouTuber had them and started asking "do I actually need this, or does it just look cool in a demo?"
The tinkering is the learning. The mess is the process.
There's a certain type of programmer who looks at someone like me and says "that's a waste of time, just use the defaults." And look, I get it. Pragmatism is a virtue.
But there's something those programmers are missing: the act of configuring your environment forces you to understand it. You can't set up an LSP without learning what an LSP is. You can't write a keymap without thinking about your own workflow. You can't structure a Lua config without picking up at least some programming instincts.
Tinkerers aren't wasting time. They're learning sideways.
Tmux: The Part Where I Become Insufferable at Screen Shares
I need to talk about Tmux for a second.
Tmux is a terminal multiplexer, which is a fancy way of saying "multiple terminals in one terminal, with sessions that persist even when you close everything." It sounds niche. It sounds unnecessary. Every person I've shown it to in a screen share has said some variation of "wait, what just happened" followed by either genuine curiosity or quiet concern for my mental health.
I love it.
I have a Tmux session for every project. I detach, I reattach, I split panes horizontally and run my dev server on one side and my Neovim on the other. My workflow is a single terminal window and nothing else. No alt-tabbing. No losing focus. Just me, my keyboard, and a black screen full of text that somehow builds web applications.
Is this more efficient than having a normal setup? Genuinely, yes. I think so.
Is part of the appeal that it looks like I'm doing something extremely technical and impressive at all times?
...also yes. I'm not a saint.
There's also this other thing that happens during screen shares that I didn't expect: occasionally, someone will see my setup and just light up. Not confusion — recognition. They'll say something like "wait, are you using Neovim and Tmux?" and suddenly we're talking like old friends. It's happened with developers I've never met before, halfway across the world — and as a Filipino working remotely, that moment of unexpected connection hits different. It's like stumbling into a secret club. The terminal is the handshake. It's a small community, but it's ours.
Why You Should Try It (Even If You Don't Stick With It)
Here's my honest take: you don't have to use Neovim or Tmux forever. You don't have to commit. You don't have to throw away VS Code or Cursor or whatever IDE is paying your rent right now.
But you should tinker with something outside your comfort zone. Configure something from scratch. Break it. Fix it. Break it again. Name the repo something embarrassing like neovim-final-final because that's just the natural endpoint of caring about your tools.
Because here's what I've found: programmers who understand their environment write better code. Not because Vim makes you smarter (it doesn't, I've tested this on myself), but because the curiosity that drives you to customize your editor is the same curiosity that drives you to understand your codebase. It's the same instinct.
The tinkerers are the ones who ask "why does this work this way?" instead of accepting it.
And that question—why does this work this way?—is the most important question in this entire profession.
Go Break Your Config
Stop using default settings for everything (unless you have a deadline, in which case: godspeed, use VS Code, no judgment).
But when you have a free Saturday? Crack open a Neovim config. Spend four hours on a keymap. Name the repo something ridiculous. Feel the specific joy of your editor doing exactly what you want it to do.
It's worth it. I promise. And if you nuke the whole thing and start over, that's fine too.
That's just neovim-final-final-v2 waiting to happen.
Enjoyed this? Follow me for more programming blogs where I justify my terrible life choices with technical reasoning.
Catch you in the next one. 🚀
Top comments (0)