The IDE Cooked My Brain

When I first began programming, I used notepad.exe. How awesome it was to rename a simple text file with a .bat or .cmd suffix, double click it and have it execute! Ohhhhhh. I felt like such a computing god when I was a youngling. Pretty much went to shit from there…

Once the novelty of writing process-fork bombs wore off, it was time to move onto a better language with more power called Visual Basic. In addition to the language change came an amazing text editor, or my first IDE, Visual Studio 2010 ULTIMATE. It had Ultimate in the title yet constantly required feature updates and bug fixes. It was far from Ultimate. Notepad never stopped me in the middle of thought by screaming and flailing its ugly message boxes for attention. However, it’s hard not to get sucked in by the colorful text editing experience, the big beckoning green play button, and the endless drop down boxes that made VS feel so feature rich.

Like most software devs, I enjoyed trying other IDEs from that point on. During university, we were forced to learn the devil’s language, Java, leading us to being recommended to use Eclipse. Eclipse was great in the beginning and the shortcuts made more sense and everything felt cleaner. Subsequent versions of Eclipse seemed to get clunkier and clunkier.

After departing university and becoming one of those “full stack” dotnet devs, I was back to using Visual Studio. The logo was new and looked flashy due to the adoption of the material design aesthetic, but it was still 32 bit and greedily abused my computer’s memory. Consider the quote from british comedian Jimmy Carr, “You can’t polish a turd but you can roll it in glitter.” ¹

IDEs are great in concept. They offer a wide range of features to enhance the developer UX. There are some developers that have become entirely reliant on their IDEs working and suffer performance issues when they stop. Given the role of the IDE at the heart of many devloper workflows, it’s hard to understand why so many people put up with the issues they cause. The issues that annoy me the most are not necessarily feature related.

Performance is important. Or at least, the perceived performance of something is important. Web developers and UX designers realised that users would quit their website if anything took more than a few seconds to load. Then lazy loading and tiny spinners on every little component on webpages became more common. Even if there was no change in performance in regards to loading data to populate those components, users could see something happening so their retention was much higher. Every painful second of waiting for something to load reduces a website’s user conversion rate by just under 4.5% ².

The IDEs I’ve used daily over the past few years, some named, some unnamed, are all prone to the same performance problems and they seem to be getting worse at handling it. I’ve never tried to crack open VS to understand why it’s become such a monster but sometimes I wish I had the time to. On a fresh laptop with 32gb RAM, >3.5GHz processor, with a 64 bit Windows 11 install, Visual Studio 2022 (also 64 bit) can completely shit the bed during a search of the Solution Explorer window on a small solution consisting of 5 projects and just shy of 300 .cs files. This is only the tip of the friction iceberg which threatens to sink my Titanic of progress each time I use this cursed IDE.

VS Code was originally quite a good alternative to its overweight memory hogging older bro. With a very active community of plugin creators, there is nearly a tool for every problem available in Code. Start up times have become unseemly again even with only the few plugins I consider essential in my workflows, such as Git, and the language specific tools for Rust, Golang, and C/C++. Feature bloat threatens to make this previously light weight application explode. Most features are opt-in things that I couldn’t care less about, but the problem arises because they exist in the binary and have a start up time impact. It is bound to happen with any application. More features, more start up time; might as well be a law. However, not everything about Code is bad even though I will rarely use it anymore. Microsoft came up with the Language Server Protocol (LSP) in 2016 while continuing to develop VS Code ³. The LSP is one of the coolest features to fall out of text editor development and it is in the realm of coolness as Vim Motions and Tree-sitter ⁴.

I use Neovim. I started using it because I thought it would be fun to be able to interject “I use Vim btw” into random conversations. It was all to fuel my meme addiction. However, I couldn’t let go of it once I started using it. The challenge of learning Vim Motions wears off quickly as it becomes muscle memory and it then silly to edit text in any other way. The trope is that Vim saves you time when editing and at the heart of that is Vim Motions which is often the aspect that puts people off learning it. It is very confronting as it is different. At some point in your life, typing on a keyboard was new and difficult but it became muscle memory. Truthfully, I’ve saved exactly 0 time when compared to my typing ability in any other IDE. That is ok though because I have saved myself from something else that I find more diffcult to deal with in software development: friction.

Friction is everything in your workflow that slows down progress. Every time Visual Studio east up all of your memory and slows itself and every other process on your machine down is a prime example of this friction. When Code dies when opening a log file because it’s a little too long, that’s more friction. Moving the mouse to click on the endless drop downs or trees in the UI is friction. There are compounding levels of friction when changes to the UI occur and then the mouse moving exercise becomes a Where’s Wally game. I may not type fast (~80wpm at my best) regardless of editor, but I’m more confident that Neovim induces less friction, and that makes me more productive.

IDEs have a habit of creating friction. I could give many examples of tasks that should be background jobs but somehow end up blocking the UI thread and in doing so disabling my keyboard input into the open code file. I should not have to wait for a Solution Explorer search to complete before I can resume editing the file I’ve already opened. These activities should be completely decoupled and unrelated. Input lag is high friction. Neovim’s available plugin systems and plugins are typically well written by other developers that have taken this type of friction into account. Plugins with potentially long running actions will palm off the work to an external process and listen for the results. The developer/terminal I/O bromance is never disrupted and I’ve never experienced input lag in Neovim.

Neovim is not an IDE out of the box but that is one of the things that makes it great. It is always light weight, unlike VS Code whose base feature set constant grows as fast as its extension marketplace grows. Using pre-configured Neovim environments like NvChad⁵ or AstroNvim⁶ will make it a full-blown IDE supporting the LSP for many of the most common programming languages and tools and they are as simple as a git clone to install once you have a Neovim installation on your machine. Using a pre-configured Neovim environment is the best way to try Neovim in your software development workflow if you’ve never used Vim before. If you like the way it feels, then try kickstart⁷ to build your own Personal Development Environment (PDE). Kickstart is a single file configuration for Neovim which is well documented to explain how to set up anything you want in exactly the way you want it.

When the cognitive friction has cooked your brain and every IDE seems to piss you off, try Neovim. It is just a terminal text editor, and it only has features beyond that if you choose them which solves the feature bloat pain. If you want it to be a marvelous IDE with features that rival the competition, it can be. And it’ll never stop you from continuing to write code just because Git is having a spasm and taking too long to fetch.

When you’ve mastered Neovim, then try Arch Linux and become a wizard.