The Habitats of Wild Programmers

Image by Pakata Goh on Unsplash

If a programmer is a knight, then their integrated development environment (IDE) is their legendary sword. Under the cover of dark mode, they speed through the plains at 200 wpm, reining their horse with custom key bindings from an ergonomic gaming saddle.

If you really can type that fast and spend eight hours a day coding, putting so much emphasis on your setup may benefit you. If not, It’s probably a waste of time.

Right after the allure of choosing the “perfect programming language” comes the “perfect environment” for it. Or worse, for all languages you intend to learn. It is laughably easy to get trapped in pondering what programs you should install to optimize your productivity… even before actually learning the languages you want to use. Such a view is based on a flawed concept of an end goal, where you believe you know exactly what tools you will need in the distant future. Coding at any meaningful capacity will never be predictable. The vast majority of time spent by a programmer is on testing, debugging, and looking up the errors on online forums, rather than writing new code.

The software you use to write your code is not unimportant, but more often than not it has far more features than you actually need. If you are a programmer, you need to be able to adapt quickly to different software, which is difficult if you’ve bound yourself to a specific setup with custom key bindings or a non-QWERTY keyboard. Thus, you should not hesitate to use different software if practicality calls for it. For example, many “programming languages” are actually just advanced scripting languages, such as Python or Javascript. These produce code that doesn’t need to be compiled to be run. Scripting languages are usually used in code/text editors rather than full-blown IDEs.

IDEs tend to have way more features than code editors, but for most purposes, there are only two significant differences: 1) IDEs often require you to set up “projects” before you can run any code, and 2) they have a compile button for languages that require compiling. VSCode and Atom are examples of code editors. You can technically run, say, Java on VSCode, but setting it up to compile the files before running them is usually a headache. Since scripting languages tend to be easy to run, you can usually work with them using just a simple text editor and a terminal without much grief.

Speaking of terminals, there is another category of text editors that has its own following. Terminal-based text editors such as Vim are known for being some of the most efficient, due to their many key bindings. Vim in particular has quite a high learning curve and can be customized to the point of being an IDE. I don’t believe that it’s worth the learning curve if you don’t already code for many hours a week, but I would suggest learning just the very basic keys for editing, saving, and exiting. It’s useful when you work with servers since it tends to be pre-installed in Linux-based operating systems. It’s also kind of a meme that Windows users don’t know how to exit Vim.

But wait! There’s one important detail I left out: setting up this stuff is ~fun~. Yes, I spent the past several paragraphs explaining why it probably won’t give you any practical benefits, but that doesn’t make it boring to do so. If you just enjoy searching for lists of “Top Ten Best IDEs in 2021,” there isn’t much harm in over-engineering your setup; to say otherwise would just be a call for conformity. In my book, if you have fun with it, then it isn’t inherently a waste of time.