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)1 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.
One may argue that a pimped up (NEO)VIM – or Emacs, for that matter –
is actually an IDE, but that’s not the point I want to make. ↩︎