It’s 2023: are we still fighting the editor war?

Screenshot of my editor setup, using Neovim with gopls LSP, inside Tilix. See my configuration dotfiles.

The editor war

When Unix culture became popularized, the community quickly found itself entertaining fierce discussions. Put a bunch of programmers in a room and they’re bound to disagree about the merits of operating systems, programming languages, version control systems and even indent style. One of these “holy wars” was the rivalry between users of Emacs and vi(m), also known as the editor war, which — according to sources — has been going on at least since 1986!

Today, this so-called “editor war”, seems far from over. Channels like Reddit, HackerNews or Medium are ripe with people proclaiming (sometimes shouting) which tool is “best” (usually, their editor or IDE of course!), and I used to be very reluctant to get involved. When I first started working in software development I briefly used Komodo and Spyder, before joining a company that used SublimeText and, later on, VSCode. I was happy with all of these tools, and didn’t care for foul-mouthed fanboys of this or that editor du jour.

Recently, however, I have come to appreciate these discussions (if civil, of course) and especially the critical reflection of which tool is best for you. Because, let me be clear from the start, there is no such thing as “the best” editor.

The right tool for the job

Which editor is best for you, is a highly personal matter. It depends on a lot of factor, such as personal preference, but also the work you do. A Python developer might prefer PyCharm, because it arguably has the best tooling for Python development. A data scientist will be very comfortable using VSCode, which has excellent integrations for Jupyter Notebooks. A UNIX sysadmin might prefer Vim because it integrates seamlessly with a terminal workflow like tmux… And sometimes, like on a remote system, your only choice might be to fire up vi…

Only a fool never changes his mind

In other words, the editor or IDE you use should be a deliberate choice based on your development needs and a comparison of the available tools. This means that there are good reasons to at least consider switching editors once in a while. Just like a carpenter would not use the same tools throughout his career, software development tools constantly evolve. And so do the people who use them (which is why the tools change in the first place). Indeed, only a fool never changes his mind. Moreover, critically reflecting on how your develop and which tools you use can be a great way of introspection and learning.

Enjoy yourself!

When I recently switched from VSCode to Neovim, there were two main reasons. The first was, without a doubt, personal taste and enjoyment. This reason might seem whimsical or besides the point, but as software developers we spend the majority of our time in our editors, so I think it’s vital this should be a pleasant experience. If you’re working in a boring, frustrating or unattractive environment, it’s bound to have an effect on your disposition, and hence your work. So find something you like and enjoy using. It’s only going to make your work better not only because you’re in a better mental state, but also because you’ll enjoy learning how to get the most out of your tool.

Being in the driver’s seat

The second reason I prefer my current editor is control. Perhaps I just never understood VSCode as well as I should have, but with Neovim I feel in total control. I understand every bit of the configuration, including the more complicated stuff like language server integration, auto-completion with snippets and syntax coloring. I like that my primary tool only does what I want it to do, only changes what I can fix myself, only shows what I think is important, only updates when I think it is time, and so on.

Challenge what you know

Not only am I more in control, I am much more aware of the capabilities of my bread-and-butter tool. I’m sure VSCode or other editors have ways of doing this too, but (Neo)Vim’s powerful (regex) search and replace, repeating the last action (.), and scriptability (with Lua or just plain :! shell commands) were game changers for me. You see, if you’ve been using a tool for long enough, you adapt to its capabilities, never realizing that there might be a faster, better way out there. Ironically, this is probably the reason why many people are reluctant to consider changing their editor. What they know, is what they like. However, challenging what you know is an important skill both in life and in software development.

Think ahead

When I first considered migrating away from my previous setup, I actually thought it would be very hard to accomplish. You see, where I work, we use a set of bespoke file types, each with their own syntax, snippets and workflow, which was fully integrated in my development environment as VSCode extensions. Another vital extension offered a GUI wrapper to a custom CLI tool we use for deployment and version control, which is also indispensable for our work. So before I could use Neovim for work, I had to write my own syntax files and plugins to replace these. Not only was this very easy to accomplish with the builtin Lua interpreter, by doing so I now feel much more independent of my editor. It is never a good idea to be married to a piece of technology. You never know when you’ll want (or be forced) to change it for something else. So, you could say, paradoxically, that moving to Neovim has made it easier for me to move away from Neovim if I wanted to in the future!

Smooth like coconut oil

Most editors promote a specific type of workflow. Some integrate seamlessly with testing and debugging environments, others excel at editing and comparing several files side-by-side, possibly with previews for markup like Markdown or reStructuredText. Still others, like Neovim, are really well-suited for hopping between the terminal to the editor and back. Considering your typical development workflow and which editor is best for that, is also a worthwile learning experience. The most important areas you can look at for improvement, are the actions you perform hundreds of times a day. Things like file navigation, running unit tests, refactoring a piece of code, … If you can improve one of those, it’s going to have an enormous effect on your workflow, both saving you time and making your life easier. “You want to be smooth as coconut oil” — as one Netflix engineer and popular YouTuber would say …

Listen to your body

Something quite akin to development workflow is ergonomics. Again, if you’re going to use a tool for hours on end, you have got to feel physically comfortable with it. For me, being able to use keyboard-based editing, file navigation and version control (I use lazygit for this), had a surprising impact on the neck and shoulder issues I was experiencing when I used the mouse more often. For the record, Neo(Vim) is not the only keyboard-oriented editor out there. If your interested, you should checkout Helix and Lapce too, and of course, Emacs ;-)

Know thyself

I hope you will now agree that exploring editors is an exciting experience which will make you a better developer, even if you stay with your current setup. It’s a process of reflection, at the end of which you will have a better understanding of how you work and why you work the way you do! It’s 2023: the time of the editor wars of yore should be over. But in an era where programmers face increasing competition from AI code generation, self-critical reflection is an absolute must.

Hi! 👋 I’m Tom. I’m a software engineer, a technical writer and IT burnout coach. If you want to get in touch, check out https://tomdeneire.github.io