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”.

13949712720901ForOSX

The cryptic title refers to a blog post asking for Java 6 on Leopard (Mac OS X 10.5). That’s old news, and to some it’s a closed issue, but not to the rest of us (who still have Core Duo CPUs).

As SoyLatte has proven, there’s no technical barrier to Java 6 on 10.4 (or on 32-bit CPUs), so I can still hear this issue faintly whispering, “I’m not dead yet!”

Neely’s Laws

I first wrote down these observations ten or fifteen years ago, as a result of several tongue-in-cheek conversations. I recently had occasion to apply one of them, so I thought I might as well post them here. Please don’t take them (or me!) any more seriously than I do.

However, I might observe that the first post of “The burden of FP” series can be read as an extended statement of Neely’s Third Law.

---

Neely’s First Law

(Monotonicity of Complexity)

Complexity is like entropy;
you can’t decrease it and doing almost anything increases it.
You can hide it, cover it up, pretend it’s not there (until later),
or make it somebody else’s problem,
but it won’t go away.

---

Neely’s Second Law

(The Means/Ends Dictum)

Solve the problem;
don’t solve the solution.

---

Neely’s Third Law

(The Blind-Spot Mandate)

In any systems design effort,
begin by carefully documenting all your unconscious assumptions.

---

Neely’s Fourth Law

(The Focus Figment)

A tool is an instrument for limiting the types of work you are able to perform.

---

Neely’s Fifth Law

(The Skills Lifecycle)

Necessities become options become obsolete become artforms.

---

Neely’s Sixth Law

(The Intuition Impasse)

“Common sense”
is an oxymoron.

---

The way to take notes

OK, I enjoyed taking notes at JPR08 with the EeePc, but this guy’s notes are the best I’ve ever seen! I just had to point you to them.