My Thoughts on Choice of Text Editors and Cognitive Biases

How to choose a text editor boils down to decision-making, but most of discussions over pros and cons of editors usually escalate into flame wars. While the lack of quantifiable indicators may lead to our disagreement, cognitive biases contribute a lot to our obstinate decision of picking text editors.

From the perspective of performance of programs, text editors can be measured in different kinds of response time. Microsecond-scale feedback in every operation is desirable. But an editor being slower for 300 milliseconds as a whole or being significantly slower in uncritical scenarios doesn’t necessitate the loss of users. For years Emacs has been derided by Vim users because of its slow start time, which doesn’t keep users from using it. Having been criticized of sluggish startup and visible lags between keystrokes, Atom, the new competitor in the editors game, has already become a popular text editor among developers.

On the other hand, productivity, which is hard to be quantified, is much touted by editors’ fans. Emacs users argue they can do almost everything including brewing coffee through endless plugins; Vim users insist that model edit provides the most efficient way of text operations and VimL extends the functionality as much as Elisp does; Atom users believe that by introducing advanced web technologies they can push text editing to a whole new level. Their arguments sound encouraging but aren’t backed up by facts and numbers. How much time does Vim’s model edit save on coding compared to other editors’ keybindings? How much do the plugins Emacs speed up the coding process? What issues have been or will be solved by Web technologies but can’t be solved by 70’s or 90’s technologies, and how much do those issues relate to the increase in the productivity of software development?

When it comes to choosing an editor, we don’t have those numbers, and we don’t make our decision based on them. What do we usually do? Here is a more common scenario: On a web forum for developers, there is a prestigious guru named George, who is skilled and has hands-on experiences in many areas of programming. He has coded programs in COBOL on mainframes, created GUI in Delphi applications and developed websites with Rails. He uses and loves an editor, OmniEdit. He once wrote a post <Why do I use OmniEdit for development>. The post not only introduces the fancy UI of OmniEdit and sophisticated features but also shows tips of using OmniEdit and how to hack it. Apart from George, other gurus like Sanji and Niji also use OmniEdit. Presumably, some developers are using Emacs or Vim. One day, Fred, a newcomer who knows nothing about programming, visits this forum due to its widespread reputation. After reading many posts about programmings written by gurus, he thinks highly of them and decides to learn to program on this forum. George’s post <Why I use OmniEdit for development> influences the newbie a lot, and thus he picks OmniEdit.

Why does Fred pick OmniEdit over other editors? Because George is skilled and experienced and his post about OmniEdit is a detailed and personal story, his accounts can be very influential to a newbie. Fred believes the editor that are used by expert developers like George is the most productive and is an indicator of an expert to some extent. He equals using OmniEdit to high productivity and even expertise.

Apparently, Fred makes a mistake. Experts using OmniEdit doesn’t imply expert-level productivity causally. They are actually two independent dots, but George’s story connects them with a cause-and-effect arrow. Therefore, Fred picks OmniEdit. In fact, he is just a victim of narrative fallacy. While continuing his learning on that forum, Fred will further exacerbate misunderstanding of the relation between OmniEdit and experts, which is accounted for by confirmation bias. If Fred becomes an expert years later, he will probably write a post or an essay about the editor he uses along the way. Another newbie will come across this post and thus embark on the same route. The plot of this story may vary a little. For instance, George might switch to Vim and Fred will follow, or he will “defect” to Emacs if he stops looking up to George. Despite those variances, the underlying reasons for changes largely remain the same.

Our cognitive biases are unnoticeable when we are making decisions. We don’t do it rationally as we think. In fact, it is very hard for us to be rational. In his profound and illuminating book <Thinking, Fast and Slow>, professor Daniel Kahneman writes:

As in judgment, we observed systematic biases in our own decisions, intuitive preferences that consistently violated the rules of rational choice.

However, that we are at loggerheads with each other over text editors may reveal a fact that there isn’t an editor good enough to distinguish itself from the rest in that every editor has both attractive advantages and tolerable disadvantages. In 2005, most mobile phone manufacturers tried to profit by producing cellphones of different form factors to accommodate customers, whereas iPhone unexpectedly came out and dominated the market in the following year and a new era of mobile computing began, so to speak.