Why I abandoned IDEs
I’ve held many different roles in my career, from developer to CEO and just about all kinds of positions in between, but I’ve always, always developed.
For me, it’s not only a source of pleasure, but also and above all an imperative necessity to continue understanding and mastering the ultra-technical and ultra-fast-moving environment in which we evolve. I consider it necessary to be able to make quick and informed decisions.
I know it’s a controversial subject, but I believe that a CTO, an engineering manager or, even more so, a lead dev should know how to code and must code, either professionally or for personal projects.
During these 20-plus years of more or less intensive software programming, I’ve had the opportunity to use a wide range of development tools and IDEs.
Lately, I’ve been gradually moving away from the most sophisticated tools in favor of lightness and efficiency.
Let me explain my journey.
My journey on development tools
The 2000s
I entered the professional market in the early 2000s.
The Internet bubble had burst, but Web dev was still booming (see this article).
The “Web-oriented” languages (i.e. everything but C, C++) developed in the 90s (JavaScript, Python, Java, etc.) were improving, and development tools were following this trend.
This was the heyday of Eclipse IDE (released in 2001), Visual Studio (1997) and others that have more or less disappeared.
It was also a time of (futile) resistance to more specialized tools from proprietary environments such as SunOS, HP-UX and AIX.
At the time, I had to navigate between a large number of them, without becoming particularly addicted to any one of them.
2010–2020
I found myself CIO of a company with 3,000 employees in 2010, itself part of a group with 140,000 employees.
My duties shifted towards management, but fortunately I managed to keep my close links with tech in general and code in particular.
This was also the period when I discovered IntelliJ, the IDE of choice for Javaists.
Admittedly, it was a bit of a revolution. Unlike Eclipse, which invariably ended up looking like Frankenstein’s creature, IntelliJ came with an “all-in-one” / “batteries included” approach.
For a very long time, it was (and still seems to be in many respects) ahead of other IDEs on the market, which explains its massive adoption.
In 2017 I co-founded a startup whose mission was to develop a platform for managing paramedical replacements with contractual automation (a kind of Uber for the paramedical world).
Taking on the role of CTO of a company that was just me and my partner in the early days, I switched back to intensive coding mode. I had to design the whole system, develop the MVP and the next steps.
IntelliJ remained my main working tool, no longer for Java, but for Scala (which it knew how to handle very well) and GoLang (which it also knew how to handle very well).
The “intelligent” autocomplete functions began to look convincing, and the scope of the tool continued to expand (database management, SQL querying from code, code consistency checks against database schema, HTTP query management to test APIs, etc.).
It was as 2020 approached that the cumbersome nature of the tool implied by all these features began to annoy me.
Some of the developers we had recruited for our startup preferred to work with VSCode, which had reached maturity.
So I tested the tool, and realized that the gain in performance and fluidity in my workflow more than made up for the (relative) loss of functionality.
2020–2021
We sold our startup in 2020 and I set up my own consulting/development company, mainly to take part in two projects for which I’d been approached.
The first was to help reorganize and refresh the product catalog of a medical imaging software company. The second was a project to design, develop and deploy all the software and infrastructure needed to carry out the agricultural census of Bangladesh.
Once again, I found myself in a position where I had to “get my hands dirty”, mainly with Rust and Golang this time (with a lot of Kubernetes yaml files…).
VSCode is still my go-to tool, but as with IntelliJ, the more I spend my days in it, the more I become aware of its little lags, slowdowns and bugs.
It occurred to me that the good old tools I’d had the opportunity to use at the start of my career (VIM to name a few) had probably had to evolve, and that it might be possible to achieve the same level of productivity without having to bother with a VSCode that looked more and more like Eclipse with all its plugins.
During this period, I attended a developer’s conference where the speaker gave a convincing demo of NeoVIM (customized as it should be), which finally convinced me.
So I began to spend an infinite amount of time trying to configure NeoVIM just right, and realized that it was almost a national sport (there are thousands of Youtube videos of guys silently filming themselves configuring their NeoVIMs, and I’m pretty sure there are Twitch videos on the same theme).
Now
Today I’m a “Service Unit Manager”, one of the types of position that exist in the organization I set up in my current employer to solve a problem of product stagnation, team re-dynamization and ownership enforcement.
Basically, I manage a team that is responsible for a product (in this case the IAM of a Cloud Provider), from design to runtime, including of course development.
My role is to manage a small (but multi-skilled) team through all these stages.
Once again, my time is divided between management, product definition, infrastructure management and, of course, development.
At the end of 2021, I discovered Helix (almost) by chance (I was looking for a Rust version of NeoVIM).
Helix is a kind of “battery included” NeoVIM, i.e. the best of both worlds: the lightness and efficiency of a terminal-mode (modal) editor without the mess of configuration and plugins that NeoVIM requires.
Although this is a relatively recent project, it has evolved rapidly and is now fully mature for everyday use, whether for coding, writing docs, managing my notes and TODOs, making my Mermaid diagrams, etc…
It’s easily extensible via the LSP protocol (popularized by Microsoft with VSCode), so you’ll find the same auto-completion, diagnostic and action suggestion functions as in any much heavier IDE.
It does not yet define a plug-in system, which is somewhat contrary to its original philosophy. But under pressure from the community, its creator finally gave in, and it’s a development in progress.
So, why a terminal based modal editor ?
At a time when Cursor and other AI-enabled IDEs are becoming ever more sophisticated, this choice may seem counter-intuitive, or even counter-productive.
It’s indeed the opposite of the tool race, but with time (and the wisdom that goes with it, there have to be some advantages), I realized that these tools ended up generating “noise” between my brain and my code.
The aim of these tools is to improve developer productivity by automating some of the tasks and hiding some of the complexity (e.g., the roughness of compilation options or the arguments used to launch a debug or unit test session).
This ultimately creates a distance between the developer and the tools (mainly the compiler) with which he actually interacts.
This distance raises several concerns:
- Firstly, the developer ends up no longer being able to develop or compile his program without his preferred IDE (not easy to write CI scripts afterward).
- Secondly, but this is a personal opinion, I find that they are detrimental to the mental representation of code structure. You navigate from a function signature to its calls with one click, through a tree structure (which can be quite confusing) with another click, and you end up not making the memorization effort needed to remember the structure of your code. And yet, this mental representation is essential for continuous code improvement. Devs don’t just think when they’re in front of their IDE (it’s probably even marginal).
When you use an editor like Helix (or NeoVIM), you feel you’re getting “closer” to your code. Helix, for example, doesn’t have a tree-like representation of the code or file structure, but instead has an ultra-efficient and fast search system.
This “lack” actually turns out to be incredibly more efficient if you have a good idea of file and code structure.
Another no less important aspect is the speed with which accustomed users will be able to work.
Navigating the code, selecting a word, a function, part of a function, editing them simultaneously — all this is done in a flash, without ever having to leave the keyboard to fetch the mouse or trackpad.
For pure text editing, modal editors are simply unbeatable for those who make a minimum of effort to learn how to use them, even on code bases of several hundred thousand lines.
But Helix is more than just a text editor: with its ability to use external tools via the LSP protocol, it provides almost the same level of information and automation as a much heavier IDE: direct access to function documentation, auto-completion, description of function signatures, indexing of code structure (who calls who, who is used by whom, who implements what, etc.).
Closing words
Modal, terminal-based editors force you to focus on your code, without distractions.
They’re incredibly efficient and increasingly comprehensive these days.
However, without AI or Copilot, you’ll have to use your brain. And maybe that’s why it’s not aimed at such a wide audience ;-)
