Avoiding the Wrong (Digital) Superpowers

(previously, I discussed the difficulty in finding the right metaphors for apps)

A good tool empowers its user to easily accomplish feats that are otherwise difficult or tedious. A great tool can be thought of as giving its user new superpowers, enabling what would previously have been thought of as impossible. Software applications can each be thought as tools for accomplishing digital tasks, and some could be thought to give their users new digital superpowers.

What I want to convince you is that digital superpowers can themselves be a double-edged blade.

An application that makes it trivially easy to divide one’s work into many small components might be thought of as giving the user superpowers, but the story changes once the user needs to actually manage those pieces. The same is true for a tool that lets a user more easily create any kind of complexity — such complexity must be dealt with eventually, and it is always more difficult to cope with than simplicity.

I’ve spent several months working on text editing, and a substantial amount of my effort has been in response to thinking about which kinds of superpowers I’ve held while using text editors. A diversity of thought on this matter has led to the creation of thousands of text editors for documents and computer code, but none have felt like they’ve fit me because each of them have given me the wrong superpowers. In this article, I want to discuss features which in my opinion outright worsen the text editing experience.

Monospace Text

I’ve already written on this subject before, so I won’t go over everything again.

To put it bluntly, the use of fixed-width (“monospace”) text in programming makes it easy for the programmer to prioritize certain aesthetics that then require extra engineering work to be usable by other developers. Using proportional fonts forces certain extra formatting and code style choices to be made, which frees up developer time to think about actually writing code. The additional benefit is that proportional text also forces the kinds of decisions that are always in line with computer defaults, which saves on engineering capacity for writing and maintaining tools to author such code.

Forgoing monospace fonts eliminates the need for the following features which are standard in most other text editors for programmers:

Any choices that make a tool simple and don’t impose additional pointless work on users is a win, and so preventing the use of monospace text is truly a no-brainer. This may make existing code difficult to read, but the user can just fall back onto one of the thousands of editors which cater exclusively to monospace. My own editor will prioritize enabling the user to write new code in a way that’s less mentally taxing.

Automatic Indentation

Source code of any computer program is conceptually divided into “blocks”. Each function defined within a source file consists of a block of code, and within each function there are various “branches” in logic which are expressed using blocks. Code within a block is typically prefaced with empty space, a visual indentation which indicates that a certain section of code exists in the context of something larger.

A very common feature of text editors for programmers is the automatic retention of the current level of indentation when entering new lines of code, also known as autoindent. It’s very useful when typing lines because it saves the user from needing to hit the tab key many times when writing code that is many levels deep within a larger structure. The problem with this superpower is precisely that it allows programmers to write code with uncomfortably deep logic.

The Linux kernel has a longstanding guideline for indentation in that no code is permitted to be indented deeper than three levels, and that most code should not be indented deeper than two levels. In other words, normal code should be indented only twice, with the occasional exception. The result is that functions which have complex logic are then required to be broken down into smaller parts. This doesn’t necessarily mean that long functions are not permitted, rather those with several branching paths should express the deepest level of branching by calling other pieces of code. This creates an overall “flatter” structure of code where simpler ideas are built up before finally being used elsewhere. It’s a strategy that leads to code files which are a little longer but generally much easier to follow in logic when looking at any one level, and it serves to aggressively prevent duplication of functionality.

Were automatic indentation removed, programmers would need to always hit the Tab key once for code within a top-level function, twice for code within a branch, and thrice for a branch within a branch. One hit of the Tab key per line is fine. Two hits of Tab per line is manageable. Three hits is obnoxious. Four or more is a very frustrating — a frustration that encourages programmers to write better code. Automatic indentation is the wrong superpower, so it is worth denying programmers this ability.

Syntax Highlighting

Syntax highlighting is the art of recolouring the text of source code such that colour becomes an indicator of what type of symbol any given text actually is. Just like how deconstructing a sentence into a tree is helpful for beginning linguists, I accept that syntax highlighting is a useful tool for beginners to spot typos and misformed blocks of code early and eliminate the frustration of hunting down for errors when trying to test code.

My issue is that once I know a programming language’s syntax, syntax highlighting becomes an annoyance at best, and a distraction at worst.

I have frequently run into issues where my entire code would change colour as I’m writing new pieces of code, usually because I had opened a new string or comment but not yet closed it because I wasn’t yet finished. When presented with such a situation I am forced to choose to either accept the discoloration or to pause my thoughts, write a closing character in the appropriate place, then resume typing. Either option puts an unecessary mental strain on me to tell me information that I usually already have. I don’t experience this when working without syntax highlighting, and so I strongly prefer to go without.

Syntax highlight gives the user the superpower of writing code like they know the language, even if they don’t. I don’t want to comment on what it means for developers to almost always prefer to have this superpower.

Code Suggestions

A less common feature in text editors (being mostly relegated to more complex “Integrated Development Environment"s or IDEs) is the suggestion of completions for names currently being typed by the programmer. This usually appears below the typing cursor as a list of function names, class names, and variable names that match or fit into what is currently being typed.

I’ve already spoken about the perils of distraction from overstimulation, so I’ll focus on another counterproductive aspect of this kind of feature: misdirection and absentmindedness.

Programming is the act of gluing together code existing pieces of code, almost always in a way which is unique and has never been done before. To program requires knowledge of which functions and capabilities are already being supplied to the programmer. A programmer who knows and understands what they have access to can quickly write up a working code solution to their problem without needing to think deeply.

As it is trivial to add complexity to programs or libraries, they tend to do exactly that: become complex and difficult to understand. Code completions are the common solution to this problem. By analyzing what is available, a programmer’s editor can determine which possible valid completions match what is being typed.

Code suggestions give the programmer the superpower of knowing all the options they have available. The problem is that the ease of use of features like this make it too easy for programmers to write code without a thought. The subtle difference between this absentminded coding from the zen programming I described earlier is that programming by autocompletion has a strong tendency to mislead the programmer. The autocompleting coder is vulnerable to picking an item from the list without properly considering it, which is often a source of esoteric and unusual bugs. The superpower granted by code suggestions is not the knowledge of what the programmer has at their disposal, but the mere confidence that they can act as if they possess the knowledge. It’s a subtle difference, but the distinction is in distraction.

By opting out of properly reading manuals and carefully considering options, you rob yourself of the opportunity to learn so deeply that you can truly master your tools and move forward with a true zen-like confidence. In this way, code suggestions become an invention for forgetfulness. I simply cannot justify writing a text editor for programmers with a feature like this.

Rich Text

Before we end, a brief detour away from programming.

Many text editors (or, word processors) for writers have features for formatting and arranging text and other visual elements on a page. These facilities are indispensable for those seeking to quickly put together a printout for consumption by others, which is likely why the programs that do this are frequently considered part of an “office” suite.

As has been the theme of this text, my issue page-oriented writing is that it detracts from the actual process of writing text, whether that be flowery prose or clear arguments to persuade. Cute images and pretty printed text wait until I’ve actually written the text — the real meat of what I’m trying to produce.

I find it far easier to simply save my changes, watch them be reflected in my browser, and continue from there. It isn’t unlike programming, really, except I don’t often need to “compile” my words to see if they still work.

Moving On

After years of programming, blogging, or otherwise writing things for myself and others, I find myself most wanting to use something that gives me the experience of parchment paper.