Words to avoid: “intuitive”

I’ve been using Stack Overflow quite a bit recently, and can recommend it as an informative source for programmers with specific technical questions. However, nothing in this world is perfect (including me! 😉 ), and some answers to this question on perl “gotcha”s hit one of my Big Red Buttons.

Warning: curmudgeonly meta-rant ahead

Some of the responses (such as “Use of uninitialized value in concatenation…”) are legitimate complaints about limitations of the current implementation. No matter the amount of education or experience, it is reasonable for a programmer to be frustrated when the run-time useful information about an error.

But as someone with several years’ experience using a variety of languages (and no particular favoritism for perl), many of the answers strike me as being complaints that perl isn’t c or c++ (or some other language which the writer prefers). I don’t talk back to my screen, but after complaints that asked (or implied the equivalent of):

“Who would have ever expected ____?”

I really wanted to say

“Anyone who read the manual!”

or

“Anyone who knew that perl wasn’t ___!”

(On a positive note, my favorite answer is this one that refers readers to the perltrap manpage. That page is a well-organized list of things that might surprise or trip programmers with specific backgrounds or expectations.)

And that brings me to today’s word to avoid: “intuitive”.

It is quite common for descriptions of computer software to describe some feature as being (or not being) “intuitive”. In my experience, that word refers to unconscious conclusions/assumptions based on the experience of the speaker/writer. I believe it can usually be replaced by the phrases “unexpected by me” or “unfamiliar to me“. A key part of those phrases, “to me“, is almost always omitted when a negative opinion is being expressed. Instead of hearing, “I didn’t understand X” (especially from a beginner), many times one hears “X is stupid” or “X is not intuitive” — rewriting an admission of the speaker’s own limitation into a criticism of the subject matter.

On a related note, during my teaching days I often encountered undergraduates — from the US — who would lament that “The metric system is too complicated.” I suggest that it is also important to be able to distinguish unfamiliarity from inherent complexity.

So what am I grumbling about? Simply this: I expect more from programmers than from users!

Suppose I am writing a piece of software to support librarians, plumbers, auto mechanics, or accountants (all worthy, important, and noble callings, chosen at random except for being very different from programming). I believe that it is my job to learn my customer’s world: the terminology, common practices, and problems that make up their daily life. Only by doing so can I serve their needs. I should enter their world, not expect them to enter mine.

In short, programmers should be life-long learners.

It’s perfectly reasonable to evaluate whether a piece of software intended for user consumption meets the needs and experience and assumptions of its intended users. But programmers should understand that different programming languages usually embody different concepts, should expect to learn something new when learning a new language (or other development tool), and should know what learning “feels like”.