In primis, I’m a physicist, not a computer scientist, and even less a software engineer.

In secundis I’m an atheist, and coherently with that this post has no ambition to show the right way to code.

Now that we made these points clear, let’s move on. As the title says, I do not use an integrated development environment (IDE)¹ to carry out my software development needs. This has made several eyebrows arch in the past, and certainly will in the future, too. I want to argue, though, that the tool I use to write software, a text editor, has actually sharpened my skills as a software developer.

What do I actually use and why?

Before arguing why I think it is beneficial to me, let me explain what I actually use to write code.

First, I definitely do not use a “plain” text editor. Even though I would technically be able to edit code in vanilla VI, Nano and the like (alas, I never learnt Emacs), I don’t do it and I wouldn’t enjoy it, just like I wouldn’t enjoy coding with a sandblaster pointed at my eyes. I use VIM, and specifically Neovim with a quite pimped up configuration.

It is beyond the scope of this post to go through my configuration, and I’m not particularly proud of it either. The internet is full of people that detailed what their configuration looks like and they are better references that I ever would. I can suggest in particular Jdhao’s blog as a source for one to come up with their own personalised configuration.

As for what are the basic enhancements over a text editor, the only real conditio sine qua non is code highlighting. Code completion, static analysis (to catch a few avoidable mistakes before compiling or running) and having the editor be able to format the code are very nice additions, but not strictly necessary features to me.

Virtuous patterns of VIM

There are some purely ergonomic advantages to using VIM as a code editor. First and foremost, I can do everything without ever getting my hands off the keyboard and without ever reaching for the mouse. This allows me to accomplish many tasks faster, at the cost of remembering key combinations and shell commands. As I argue below, this forces me to keep both mental and muscle memories well trained, and I therefore count it as a plus.

Second only to not having to use a mouse is screen real estate usage. I tend to function by opening several files side by side: my 27-inch work monitor can fit four 80-column windows horizontally side by side, while my personal 13-inch laptop can easily fit two, or three if I shrink the font a bit below my comfort zone. Very often I further partition windows vertically to have even more space to read, write, compile, execute, inspect, … Most IDEs provide these functionalities in the form of buttons on toolbars which, besides introducing distracting visual clutter, take space away from what really matters to me: the code that I’m working at.

A screenshot of the editing of this very post in VIM.

Last but not least, I can do these things on my local machine or literally on any machine that I can access a shell on. The POSIX standard prescribes a VI compatible tool on any compliant system, and very often both VI and VIM are installed.

Leaving ergonomics and entering functionality, one may argue that having repetitive tasks available as a clickable button is more convenient than having to remember some obscure key combination or shell command. However, for how I reason about code, these small annoyances actually enhance my understanding of the project I’m working on. For instance, having to rely mostly on memory instead of one-click “go to definition” functionality trains my brain to explore the source code and make a mental map of it. This map is not going to be precise, especially on medium to large projects, but it is good enough that it allows me to identify patterns I would otherwise miss. This becomes a massive advantage in not-too-large projects, where a single human can still have a global vision of the codebase.

Suffering a little pain to navigate the code has also other advantages. I feel that having to rely on mental memory for many tasks encourages self-discipline in structuring the source in a well-thought hierarchy. Infinitely nested folders and files with a single definition become infinitely more tedious and costly to keep in this mental map, and as such I tend to avoid them, striving for simplicity and consistency.

Another constriction-turned-advantage of not having functionality available on a toolbar is that when I need to do other operations such as compiling, running or interacting with the version control I need to rely on shell or editor commands…and it happens that I am already inside a shell! My terminal emulator of choice supports tabs, and sometimes I even use shell sessions within VIM itself. The tool that by far I find the most valuable to use from the command line is git, as I find it vastly superior to its usage through a GUI.

Vicious patterns of IDE

I already mentioned how I feel that the graphical interface of IDEs subtracts valuable space that I prefer to use to read a few extra lines of code, or to be able to open an extra file side by side. In the same way that it subtracts space, I also despise that it subtracts time in the form of longer startup times and background operations I didn’t explicitly request. I also think it is a bad practice to commit to version control and share IDE-specific configuration files (or any file that doesn’t contribute directly to a project’s value).

There are two more critical issues with the usage of IDEs that I want to mention.

First, sometimes IDEs hide what they are actually doing from the user. I once helped a colleague execute a slightly less than trivial merge of two git branches with a few conflicts to resolve. After many attempts we still couldn’t get the code to the state we desired, and it looked like something was always reverting back our fixes. After asking him to fire up a shell and executing the operation manually, we realised that the IDE was silently synchronising the code with upstream in a moment when it was extremely detrimental to do so. I greatly prefer to have full control of what I’m doing, and do not want an interface to take decisions for me.

The second and final anti-pattern is purely human in nature and is not so much the IDE at fault: IDEs should be an enhancement of the developer’s skills, yet some intend them as a complement or downright substitute for missing skills. This becomes evident when you start finding bugs in the code that were introduced by the programmer blindly trusting the IDE’s suggestions.

Conclusions

I shared some of the reasonings behind why I still use a text editor to code, and why I prefer it over IDEs. For those that find it more comfortable to use IDEs, I can only say that sometimes I’m a little envious, because there are definitely goodies I could benefit from. Unfortunately current IDEs don’t fit in my work patterns or the cost of adapting my current patterns to the IDE’s constraints would outweigh the gains.