Why you Should Love your Editor

Jun 13, 2025

This summer, I have had a lot of trouble finding ways to stay motivated that are not negatively inspired. Whether it be starting new projects or doing Leetcode or checking LinkedIn, each has a struggle that has annoyed me uniquely. One of the places where I don't feel this is when I am playing around with my editor, creating a space that I enjoy.

The Case for Messing with your Editor

Over the last 2 years since I have begun studying computer science, I have made a jump between environments as my skills have developed. At Purdue, we study Java first, so the obvious first choice was IntelliJ. After that, we have to take a year of C programming for DSA, Systems Architecture, and Low-Level Programming. Here, we were forced to use vim. In fact, my professor had autocheckers that on-submit would check for a .idea or .vscode. If found, you got a 0. A lot of kids like myself tried using Vim, but like most newcomers found the concept of navigating totally inside of the terminal, without a mouse too terrifying. Add in that you can't even configure your settings easily and most kids just decided to manually remove the vscode directory manually instead of going through all of the trouble.

How Good can They really be?

I am definitely not at the top of my class, but I was getting pretty comfortable working. I had added some stuff to my bookmarks, changed my colorscheme to Catppuccin, and installed some extensions. I was rolling! Then, I took Systems Programming. My instructor was an old fella, who used acid green stock standard vim. No syntax highlighting, no plugins, just pure vim. And he was fast. Watching him code was like watching someone speak a different language fluently while you're still sounding out syllables. That's when I realized vim wasn't just about being contrarian or proving something. It fundamentally changes how you interact with code.

The Vim Revelation

The learning curve sucked. But once modal editing clicked, everything changed. You stop thinking about moving a cursor and start thinking about text objects. Delete inside word. Change around paragraph. Jump to matching bracket. It's less like using a tool and more like having a conversation with your code. For backend work, vim became essential. SSH into a server? Vim's there. Quick config edit in a Docker container? Vim. No waiting for VS Code to load, no Chrome eating half your RAM. Just you and the text. That really got me was how it forced me to actually read my code. When you can't mindlesssly click around, you start understanding the structure. You learn where your functions live, how your modules connect. The code becomes less abstract.

The Community Surprise

I expected vim users to be insufferable. They weren't. The r/vim subreddit became daily reading - people genuinely excited to share tricks that save hours. Every week someone would blow my mind with something I didn't know existed. Marks? Macros? Registers? Each discovery felt like unlocking a new ability. The community taught me that configuration is personal. There's no "right" .vimrc. You build it piece by piece, solving your own problems. It's yours.

AstroVim

After a year of vanilla vim, I found AstroVim through discussions on our class forums. it came with everything I'd spent months trying to configure, and it seemed more like an easy to use, full-fledged ide. Suddenly I had LSP support that actually worked. Git integration that made sense. Fuzzy finding that put VS Code to shame, and it was super fast. But more importantly,it taught me how modern editors actually work. Language servers aren't magic - they're just programs parsing your code and sending JSON back and forth. Syntax highlighting uses abstract syntax trees. Debuggers talk through protocols. Each configuration tweak revealed another piece of the puzzle. Setting up a Python LSP taught me about language servers. Configuring treesitter showed me how syntax highlighting actually works. It demystified the IDE.

Helix

Just when I'd settled into AstroVim, I discovered Helix. I was searching for it because I was having trouble with the file picker in Astrovim, and it's wide variety of plugins and package managers seemed to be getting in the way of me finding out what was wrong with my Telescope. I looked around, and eventually settled on helix. All of my work that I put into vim motions mostly carries over, but I get a ton of stuff out of the box that I had to constantly fiddle with in vim, like a fuzzy file finder that just works, and a command set that displays itself always.

What This Journey Taught Me

This wasn't really about editors. It was about understanding tools at a deeper level. Each editor pushed me further into the terminal ecosystem. I learned why :! commands work, how editors detect terminal capabilities, why Unix philosophy matters. But the biggest change was how I read code. I think in text objects now - paragraphs, sentences, words. I navigate semantically, not visually. When debugging, I trace through code methodically instead of randomly clicking. It made me better.

The Point

I don't think that Vim or Helix or any other niche editor is the end-all for software engineers. I haven't even really entered the industry, so who am I to say? But one thing I am sure is important is the value of learning your tools well to increase productivity. In the same way that AI can make good engineers great and bad engineers worse, simply jumping to Vim or VScode when you are not familiar with why you are making the switch or learning the commands can be the same thing. That being said, I couldn't be happier!

ldutrieux.dev