I tend to use a very minimal toolset when working with software. The reaction I get from other software engineers ranges on a scale from disgust to awe.

That doesn't mean I won't use Very Large Software (VLS) because I have and will. I even was the owner of Gradle and JetBrains integrations at Amazon for a while, with tens of thousands of users. Gradle longer than JetBrains. I didn't invent or revolutionize anything with these VLS offerings but it did meet people at their preferences.

The broad preferences of the software engineer pop culture where I'm from looks something like this:

• Multiple monitors, or a very large curved monitor
• An Apple laptop
• Apple peripherals, each with the appearance of minimalism (but inevitably: a mess of cables and dongles everywhere)
• Mac OSX is a development platform, but the most common targets seem to be browsers or Linux containers.
• Some top-20 programming language with a preference this decade for gradual typing, primarily to assist an IDE-assisted programming workflow
• Some popular IDE that's standard for the language. Maybe something like VS Code (and an electron application can be considered a "light" tool these days!) or a JetBrains IDE, or something that's tightly related to an operating system like Xcode or Visual Studio.

Now, this is not bad, and it might be the cost of doing software at all in your context. I don't think anyone should feel ashamed for being in the status quo. Some of the details will change over time: the baton has passed from Apple to Microsoft and back to Apple for hosting most software developers.

But... this it's also just not my style.

I like a small screen and a dumb text editor. I don't just think this is an aesthetic choice, but a choice I've come to appreciate for more practical reasons.

It's very difficult to work on a modern software project without an IDE. You need to be able to reconcile a complex call graph, at multiple levels of abstraction, through multiple source files, maybe even through multiple source repositories and projects, each written by an every-changing cast of contributors that might not have a full picture of the project.

When I work on a small screen, that sort of project doesn't work very well. That's part of the plan, though, and gives me an incentive to simplify immediately rather than in some speculative clean-up we all agree that we should do in the future.

I've hobbied and worked in software for a while, and had the opportunity to work on Amazon's ~20 year accumulation of polyglog libraries, daemons, scripts, and build tools. I can tell you that the statistical probability of actually getting back to that minor refactor we all want to do (but later) is near zero.

That said, I can also tell you that valuable code that's simple is an enormous asset, and that valuable code that's complex is a liability. What constitutes value is the subject for some future discussion, but there is a spectrum between the code in that "script I wrote and ran once" and the code running a pacemaker or a car's anti-lock breaking system.

I aspire to create software that is particularly valuable. I expect that at the same time, the majority of things that I create will probably be of little value to anyone but myself. In any case, I'm interested in training myself to always create minimal solutions so that when something valuable does get created, it will be an asset rather than a liability.

A brief aside on Linux (or BSD, Plan 9, etc)

Neal Stephenson once made an analogy that Apple and Microsoft operating systems are like cars you can buy from dealerships, and Linux is more like a tank that you can get for free.

Those who have really "gone to war" in a Linux context, especially systems administrators, "Site Reliability Engineers," "System Development Engineers" and similar, might feel a spiritual connection of sorts with this analogy.

I don't know how deeply Stephenson was considering this analogy, but I do have a history enlisting in the USMC and some passing exposure to tanks and tank simulators. They are VERY NOT designed for comfort, beauty, or pleasure. The controls expose everything the vehicle can possibly do. The view to the outside is there, but in ways obstructed to bring focus on what really matters in its context.

It's definitely not going to be everyone's preference to have all this control. It's dangerous, with a large capacity (sudo rm -rf /) for destruction.

Like Linux exposes you to your machine more than other operating systems, pure text editing exposes you to the essense of the source code. It's interacting with the "everything" of the text. I also believe the limitation in how much can be displayed at once is valuable.

IDEs layer on many comforts, and are more pleasant to use. But: the comforts they bring also come packaged with incentives for excess and complexity.

Update on 2024-09-18: I now work at Furnished Finder and some legacy components have hard requirements on old versions of Visual Studio IDEs. These are valuable components to the company and its users, and so there is a hard requirement to use these IDEs when developing. Newer developments like mono, dotnet core, etc are not compatible, but they generally follow the trends of moving away from IDEs as a dependency. It's also a clear liability to the company that we're working to get away from.