Your IDE Is a Status Symbol. Sublime Text Is a Tool.

You’ve probably noticed it by now. The spinning loading wheel when you open a moderately large JSON file. The agonizing 15-second boot time just to change a single variable. The endless barrage of pop-ups, sidebars, and context menus demanding your attention before you’ve even written a line of code.

We have accepted this friction as the cost of doing business. We fire up JetBrains or VS Code, wait for the indexing to finish, and tell ourselves we are doing “professional software development.” But let’s be honest: we’ve optimized our workflows to make us feel smart, not to make us fast.

Look at the unspoken hierarchy in developer culture today. JetBrains sits at the top, signaling deep, enterprise-grade competence. VS Code sits in the middle, signaling collaborative, modern flexibility. And Sublime Text? It gets dismissed as a glorified notepad, an extended clipboard, a tool for quick edits but never for “serious” work.

This isn’t a debate about capability. It’s a status signaling game.

In modern software development, complexity has become a proxy for competence. If your editor doesn’t consume 4GB of RAM just to render a cursor, are you even a real engineer? We have conflated the sheer volume of integrated features with actual programming skill. But the most fundamental professional skill in development remains exactly what it was thirty years ago: moving text quickly and precisely.

Sublime Text endures not because of some misplaced nostalgia for the 2010s. It endures because it is frictionless. When you press a key in Sublime, the character appears instantly. There is no lag, no background processing, no telemetry phoning home to a corporate overlord. It is a pure, unadulterated connection between your brain and the screen.

The critics will immediately jump to the comments. “So what do you use for debugging?” they ask, as if the entire act of programming is just stepping through breakpoints. Yes, IDEs have better debuggers. Yes, refactoring a massive enterprise Java codebase is easier with the right tooling. But 90% of your day isn’t debugging. It’s writing. It’s navigating. It’s manipulating text. And for that 90%, you are paying a massive tax in speed and responsiveness just to keep a debugger tab open in the corner.

The twist is that we think we are upgrading our capabilities by adopting heavier tools, but we are actually degrading our core instincts. We outsource our syntax awareness to linters, our structure to tree views, and our speed to electron-based frameworks. We become dependent on the friction.

Sublime Text isn’t a relic of a simpler time; it’s a mirror showing exactly how much friction we tolerate just to look professional.

The next time you sit there, waiting for your IDE to re-index a node_modules folder, ask yourself what you are actually optimizing for. Are you optimizing for the sheer joy of writing code at the speed of thought? Or are you optimizing to fit in with a culture that judges your professionalism by the weight of your software?

Speed is a feature. Friction is a bug. Stop apologizing for choosing the tool that actually gets out of your way.

FAQ

Q: But how do you actually debug without a full IDE?

A: You use a dedicated debugger. The idea that your text editor must also be a bloated Swiss Army knife is a modern fallacy. Use the right tool for the right job, and keep your text manipulation fast and lightweight.

Q: What's the practical takeaway here?

A: Evaluate your tools based on how little they get in your way, not how many panels they can cram onto your screen. If your editor lags when you type, you are paying a daily tax in cognitive load for features you rarely use.

Q: Are you saying IDEs are completely useless?

A: No, but the hierarchy that ranks them above lightweight editors is a status game, not a capability metric. The most competent developers aren't the ones who need an IDE to hold their hand; they're the ones who understand their codebase deeply enough to write it anywhere.

📎 Source: View Source