The Plugin Graveyard Living Inside Your IDE

Open your VS Code extensions panel right now. Go ahead. Count them.

If you're like most developers who've been writing code for more than a year or two, you're probably staring at somewhere between 20 and 50 installed extensions. Some you use every single day. Some you installed once for a specific project back in 2021 and never touched again. And a whole lot of them are running in the background right now, quietly taxing every keystroke, every file save, and every build cycle you trigger.

Here's the uncomfortable truth: that plugin ecosystem you've been curating like a personal museum of productivity is probably costing you more than it's giving back.

The Promise vs. The Reality

Extensions sell themselves on convenience. A linter here, a formatter there, an AI pair programmer, a bracket colorizer, a TODO highlighter, a Git blame overlay, a snippet library, a theme pack with custom icons. Each one sounds completely reasonable in isolation. Each one adds maybe a few milliseconds of overhead. No big deal, right?

Except it's never just one. It's never just a few milliseconds.

When you stack 40 extensions on top of each other inside an Electron-based editor — which VS Code absolutely is, for all its polish — you're not looking at additive overhead. You're looking at multiplicative drag. Extensions that hook into the same file system events, that compete for language server resources, that each want to lint your TypeScript the moment you hit save — they don't politely take turns. They pile on simultaneously, and your feedback loop pays the price.

JetBrains IDEs aren't immune either. IntelliJ IDEA, WebStorm, and their cousins are heavier out of the box, but their plugin ecosystems carry the same fundamental risk. Every plugin that runs inspections, indexes files, or hooks into the build pipeline adds latency that accumulates invisibly over thousands of daily interactions.

What "Slow" Actually Looks Like

The insidious part is that extension bloat doesn't announce itself. You don't get a pop-up saying "Hey, your startup time just crossed 12 seconds." Instead, it creeps in gradually. Your IDE takes a little longer to open. IntelliSense suggestions feel slightly laggy. That TypeScript error you just introduced doesn't show the red squiggle for three or four seconds instead of one. Your terminal feels sluggish after a build.

Individually, none of these feel catastrophic. Collectively, they create a development environment that's fighting you instead of helping you. And because it happens incrementally — one plugin install at a time — most engineers never connect the dots.

Microsoft actually built a startup performance profiler directly into VS Code for this reason. You can access it by running Developer: Startup Performance from the command palette. What you'll find is often genuinely surprising: extensions you thought were lightweight are responsible for hundreds of milliseconds of initialization time. Extensions you forgot you installed are still running activation logic every single time your editor opens.

The Cognitive Overhead Nobody Talks About

Compile time and startup latency are measurable. Cognitive overhead is harder to quantify but just as real.

Every active extension is a potential source of visual noise, notification interruptions, and decision fatigue. That Git lens overlay showing blame annotations on every line sounds useful until you realize you're spending mental energy parsing authorship information when you're trying to debug a logic error. The TODO highlighting extension that marks every comment containing the word "fixme" in bright red starts to feel like your codebase is screaming at you constantly.

When your editor is doing too much, you start unconsciously tuning things out — which means the signal-to-noise ratio of your development environment degrades. You stop noticing warnings because there are too many. You dismiss notifications reflexively. The tools that were supposed to make you more attentive end up training you to pay less attention.

How to Actually Audit Your Setup

The good news is that this is a solvable problem, and it doesn't require nuking your entire configuration.

Start with the data. In VS Code, the Developer: Startup Performance command shows you exactly which extensions are activating at startup and how long each one takes. Sort by activation time. Anything over 100ms deserves scrutiny. Anything over 500ms needs a very good justification for staying.

Categorize by actual usage. Go through your full extension list and sort each one into one of three buckets: things you use multiple times a day, things you use occasionally, and things you honestly can't remember installing. The third category gets uninstalled immediately — no negotiation. The second category gets converted to workspace-specific extensions that only activate for relevant projects.

Use workspace profiles aggressively. Both VS Code and JetBrains support the concept of project-specific configurations. A Python data science project doesn't need your React snippets extension. A solo side project doesn't need your Jira integration. Scoping extensions to the workspaces where they're actually relevant is one of the highest-leverage changes you can make, and most engineers never bother.

Benchmark before and after. Disable your 10 least-used extensions, restart your editor, and actually time your startup. Check how fast IntelliSense responds. Run your test suite and see if the feedback loop feels tighter. Subjective feel matters here — your gut will tell you whether the environment feels snappier even before you pull up a profiler.

Apply the 30-day rule. If you haven't actively used an extension in the last 30 days, disable it. Not uninstall — just disable, so you can re-enable it if you actually miss it. Most of the time, you won't.

The Extensions Worth Keeping

None of this is an argument for running a bare-bones editor with zero tooling. Language servers, proper linting configurations, and formatters like Prettier or Black genuinely improve code quality and save real time. The goal isn't minimalism for its own sake — it's intentionality.

Keep the extensions that create a measurable, direct benefit to your daily workflow. Keep the ones that catch bugs before they hit code review. Keep the ones that automate genuinely tedious tasks you'd otherwise have to do manually.

Cut the ones that are there because they seemed cool in a YouTube tutorial two years ago. Cut the ones that duplicate functionality you already get from a language server. Cut the ones that add UI chrome without changing how you actually write code.

Your Development Environment Is Infrastructure

Here's the mental shift that makes this click: your IDE configuration is infrastructure. It deserves the same care and periodic review you'd give a production system. You wouldn't let a production server accumulate unused services indefinitely and just shrug when performance degrades. Your local development environment shouldn't get a pass either.

The best developers aren't the ones with the most tools. They're the ones who've figured out exactly which tools solve their actual problems — and had the discipline to leave everything else on the shelf.

Take 20 minutes this week. Run the profiler. Audit the list. Cut the dead weight. Your compile times will thank you, and so will your sanity.