Rhodri James
I should preface this by saying that this article is very much a personal opinion. It springs from the quirks of my personal processor unit (aka my brain) and the preferences I’ve developed over the decades, and clearly a lot of people disagree with me. I’ll be interested to see what the counter-arguments are, and for that matter how many people have the same issues that I do.
We went through a period a few months ago when it was popular to bash Integrated Development Environments. A lot of things have been said against them, some even accurately. They do hide a great deal of information from you, which is great right up to the point when you need to know it. The auto-generated files can be hard for a human to understand and the configuration files are downright verbose when they are readable at all. Sharing development used to be a nightmare until IDEs learned to interact with version control systems and only put the relevant files under version control. For all that, if you aren’t working on a project where you need to understand the build system, they can be extremely useful.
But not for me.
I wrote a long article explaining that the inherently visual nature of IDEs doesn’t sit well with me because while I don’t have full-on aphantasia, I am a fair way down that side of the curve. Icons don’t mean a great deal to me, and I have to consciously track things like the culturally-driven changes in what a “Save” icon looks like. From a programming perspective I am far more word-oriented; command lines come naturally to me, and I will prefer keyboard shortcuts to hunting something down with my mouse. To me it feels like I’m being inefficient if I have to take my hands off the keyboard, but that’s how IDEs were built to be used.
I then checked this against my boss, who I assumed was a very visual person from his habit of drawing diagrams, only to discover that he does in fact have total aphantasia; he cannot imagine in pictures at all, and he and I suspect that he diagrams things out because of that. Clearly my basic assumption was wrong.
I think there are two things that contribute to my aversion to IDEs. The first is that I am very verbal; I read a lot (no, really, a lot), and take in information from written sources quickly and easily. The second, and apparently more important, is that I predate them as a programmer.
I learned to code on an IBM mainframe that had (at least as far as we students were concerned) a flat filing system. There were no directories to tidy collections of files into (though there was something that almost did the job for a single directory level), so if your program needed more than one file of source code you had to be ingenious and disciplined. Basically I learned to organise projects myself because there was nothing that would do it for me.
IDEs fundamentally want to organise your projects for you, and my immediate instincts rebel against that. I already know how to organise my projects, and it’s not quite in the same way that most IDEs seem to want me to. The first time I used an IDE I hit all the shared development problems they hadn’t even realised were problems at that point, tweaking anything involved a fight with a user interface that wasn’t as intuitive as it thought it was, and even finding some source files so I could edit them with a real editor was an exercise in futility.
I do not think in the ways IDEs seem to expect me to, and that’s fundamentally why I find using them a frustrating and unwelcome experience. It doesn’t help that visual metaphors don’t work well for me, but at the bottom of it all is the fact that every IDE I have ever tried wants me to follow a workflow that just isn’t the way I work. In theory they should offer me efficiencies and facilities to improve my life, but in practice they don’t because I’m not using that workflow.
Over the years, IDEs have acquired quite a few programming-related features that almost invariably don’t do what I want. By this point I expect them to not do what I want so I don’t bother to try them out any more. In many cases I can see the point to these features, but the IDE interface doesn’t offer me sufficient control to get what I want. Therein lies the problem; these features should be separate tools. I was particularly offended by a chip that could only be programmed through its vendor’s IDE; running up a large application for thirty seconds of work is inefficient, but the vendors were trying to sell this to me as an efficiency gain and wouldn’t listen when I disagreed. This hasn’t encouraged me to keep using their products.
Arguably the very concept of the IDE itself is a lurch in this direction. I much prefer the approach of RISC OS, where the visual build tool is a simple application that runs “make” and uses your configured editor and the operating system’s throwback mechanism to take you to wherever an error occurred. You get to use the environment you prefer, not one that someone else has dictated for you. This is the Unix philosophy; a collection of small tools you can chain together are infinitely more flexible than a single large tool.
So there you are. There is some truth to my idea that the visual nature of IDEs doesn’t sit well with me, but not nearly as much as I thought. Do you find “visual” tools helpful, essential or useless? Everyone seems to be different, and I’m curious as to what people use and why.