Why I Deleted My IDE Features (And You Should Too)

Let's be honest with ourselves. How many VS Code extensions do you have installed right now? Twenty? Fifty? More? When was the last time you actually read an error message instead of just clicking on the squiggly red line?

I spent the better part of a decade accumulating tooling. Theme packs, AI autocomplete, language servers, syntax highlighters that turned my code into a rainbow. I felt productive. I felt like a professional. Then I realized I couldn't navigate a codebase without LSP telling me where functions lived. I couldn't write Python without autocomplete suggesting method names. I was not a programmer — I was a professional mouse-clicker with a text editor open.

So I did something radical. I started taking things away.

The Editor That Forces You to Learn

I landed on Neovim, but honestly, the specific editor matters less than you'd think. What matters is embracing keyboard-centric editing. Every second you spend reaching for your mouse is a context switch. Every click is a break in flow state.

Neovim gives you the power to never touch the mouse, but here's the twist — I stripped out almost everything that makes modern Neovim "modern." No LSP. No autocomplete. No fancy plugins that try to read my mind.

What does my setup look like? Black text on white. That's it. Comments get a slightly lighter shade of grey. Some developers look at this like I'm punishing myself. They're wrong.

When everything looks the same, you cannot skim. You must read. You must understand what the code actually does rather than relying on color to signal "this is a function" or "this is a variable." After three months of this, I started reading unfamiliar codebases at roughly twice my previous speed. The visual noise was gone, and my brain finally had to do what it was supposed to do.

What Autocomplete Stole From Me

Here's an uncomfortable truth: autocomplete made me stupid.

I don't mean that as hyperbole. When I started programming, I memorized API signatures. I knew that array_map took a callback before the array. I knew that fetch() returned a Promise. I earned these mental models through repetition and struggle.

Then autocomplete arrived, and I stopped memorizing. Why would I? The machine would tell me what arguments came next. The machine would suggest the right method name. The machine would complete my variable names.

The result? I became dependent on a co-pilot who was actually flying the plane while I sat back and watched.

So I turned it all off. Inline suggestions, popup boxes, AI completion — gone. At first, my productivity cratered. I had to slow down and actually think about what I was typing. Method names that used to autocomplete required conscious recall. Parameter orders that I "knew" but never really memorized became conscious knowledge again.

Two weeks later, something shifted. I wasn't slower. I was writing code with intention rather than selection. The constant "pop-up, evaluate, select" cycle had been replaced by a continuous stream of focused typing. My hands knew the APIs now. My brain had absorbed the language properly.

The Case Against Language Server Protocol

LSP is genuinely useful. I want to acknowledge that before I explain why I removed it.

Go-to-definition, rename-refactoring, inline diagnostics — these are legitimate productivity features. So why did I get rid of them?

Because they turned me into a tourist in other people's code.

When LSP shows you exactly where a function is defined with one keystroke, you never have to explore. You never have to understand the structure of a package. You never build a mental map of the codebase because the tool maintains that map for you.

Without LSP, I learned to grep. I learned to search. I learned to open files and read them like a developer rather than a user of a navigation tool. And you know what? Understanding where things live makes you faster in the long run, even if the initial search takes longer.

The diagnostic thing is interesting too. Those red squiggly lines? They train you to let the machine check your work. Without them, I started reviewing my own code more carefully. I caught my own mistakes before they became bugs. My brain adapted to double-checking syntax in real-time.

The Tools That Remain

None of this means I'm using stone tablets and punched cards. My essential toolkit is:

Fuzzy finding — I can live without LSP because I can find anything instantly. File names, content, patterns — all searchable in milliseconds.

A good terminal multiplexer — Context switching between projects should be instant. tmux gives me that.

GitHub Desktop — I know, I know. Real developers use the command line. And I do, for complex operations. But for visualizing branches, resolving conflicts, and understanding history, a good GUI is invaluable.

A fast terminal — Ghostty, Alacritty, Kitty — pick one that doesn't make you wait. Latency kills flow.

The theme? Everything else is negotiable. These core utilities are not.

The Principle Behind Minimalism

Here's what I learned: tooling should amplify intention, not replace skill.

Every "helpful" feature we add is a trade-off. Yes, autocomplete saves seconds per line of code. But those seconds cost us deeper knowledge of our craft. Yes, LSP navigation saves clicks. But those clicks taught us how codebases are structured.

This isn't about being a purist or a masochist. It's about being intentional with your dependencies. Ask yourself: "Am I learning from this tool, or am I becoming dependent on it?"

The best developers I know have opinions about their tools. They understand what their tools are doing and why. They chose their setup deliberately rather than accumulating features until the IDE barely starts in under 30 seconds.

Start with less. Add features only when you understand what you're giving up by having them. Your future self will thank you — and so will the next codebase you explore without training wheels.