Is "RTFM" counter-productive?

Question

I'm reading the very excellent The Design of Everyday Things by Donald Norman. In it, he describes a common problem:

The reason [that nobody reported a problem with the system] was simple: when the system stopped working or did something strange, the secretaries dutifully reported it as a problem. But when they made the "return" versus "enter" error, they blamed themselves. After all, they had been told what to do. They had simply erred.

A common response to many technical problems (though not so common on SOFlow, thankfully), is to simply say, "RTFM" (warning: explicit). I'm sure there are cases when this really is the best response.

But take a problem like printf, where there is mass confusion. (See this question; in particular this response and my counter.)

• The obvious parallel from printf to the written number is that "10.2f" means a float with 10 digits, then a decimal, and finally 2 more digits.
• The correct interpretation, however, is that the width is 10 (including decimal) and there are two digits after.

Clearly we can't redesign all of printf now -- too much would break. But in the next version -- let's call it aprintf, can't we make the usage match the expectation?

I think there is a danger in saying, "it's the user's fault for not reading the spec," when the spec is poorly designed.

Nota bene: I'm not saying that the design of printf is the wrong one; maybe there are really good reasons why it must be that way. But users can't be expected to foresee those reasons, so the design is counterintuitive.

In summary: blaming the user gets us designers and programmers off the hook, but it doesn't make anyone's life easier in the long run.

Answer 1

I completely agree - the system should be created to work as the user expects. This is the whole point of putting a system through usability testing.

The less that a user has to consult a manual, the better. This can be assisted by various contextual aids, like tooltips, help icons, and similar.

I firmly believe it's our job as developers/designers to make the systems as idiot-proof as possible.

Answer 2

I don't think RTFM is counter-productive in general, I personally tend to RTFM quite a bit and am often sorely tempted to tell people to do that in life :) However here, I think it's possible that questioners have already ReadTFM (and the web) and either didn't understand it or found that it left room for greater understanding.

So for SOFlow, I think it probably is inappropriate, and I'm also remembering Jeff's comments from the podcasts where this should end up as a really useful resource for programmers looking for answers to questions when searching in Google - won't be much use as a future resource if the answer to every question is RTFM :)

Answer 3

Bad user interface needs to be dealt with, but your example of printf is a different subject.

The whole development world is full of these idiosyncrasies, and I'm not sure it would be possible to iron them all out - your 10.2f is a good example. Adding yet another method would just add to the confusion.

At the end of the day, the printf style problem is all down to the learning curve.

Answer 4

If RTFM was appropriate, we wouldn't need StackOverflow. :)

Answer 5

I think there are 2 different parts to your question.

1. Uses an anecdote about users and their interaction with a technical piece of software.
2. Uses an anecdote about the design of printf() to be used by programers

Of course in the context of usability we should probably keep both simple. But I see these (I could be completely wrong) as 2 different domains.

If a coworker comes up to me and asks me how to setup apache with mod_python and I say RTFM, what I mean by that is it would be better for you to read the apache documentation and sample config files rather than for me to just tell you what to edit.

On the other hand, if a user of my software is having trouble using a particular piece of it, then I have probably done something wrong and need to make it simpler to use.

Answer 6

I like to consider the "R" in RTFM as "Refer to", not "Read".

Its like using wikipedia (bear with me): you don't quote the thing; but it's a great place to start.

/mp

Answer 7

"RTFM" is an intentionally insulting response to a question. If you have reason to believe that the asker has made no effort to handle their own problems, then maybe it is appropriate, but in general, it is simply rude. "Try Google" has similar connotations.

Users should read manuals if they are available, and do some research on their own, but that's not always the best way to find information. Maybe the user has read the manual, but didn't notice the fourth paragraph on page 1128 where the answer is. Maybe the user tried Googling but couldn't find the right answer among the 10,234,832 pages that were returned.

If answering a question is a waste of your precious time, it is much easier to simply not answer than it is to spend time insulting someone.

Answer 8

Doesn't printf use a standard method of formatting strings? It behaves exactly the same when I've used it on Java, PHP, and Mysql...

Answer 9

There are three separate interactions here:

1. Software developer to user
2. Manual writer to reader
3. Question answerer to asker

For the first, the ideal is that the software should "Do What I Mean" (DWIM). The problem is sometimes the user needs a bit of context to know how the software will react. The first time I saw a DOS prompt, I typed "hello". Computers were sort of magic at that point for me and I had no idea how to interact with them. That's why we need manuals.

Ideally, the DOS prompt would have answered my "hello" with a screen that helped me use its interface. It would have explained the mental model I'd need to interact with it. Hopefully, the model would make enough sense that I'd start extrapolating what was possible on the system and be able to do useful things with it. A good manual will provide a useful operational model of the software it explains and give details about how it operates. Ideally, the manual writer and the software developer will use the same mental model and work to communicated it accurately to the user/reader.

Now in a forum like this, the question answerer is usually yet another authority. Unlike the developer and writer, the answerer might have nothing to do with the software in question. Sometime they have an accurate model, but sometimes not. If the software and manual are ideal (as above), the only good answer is RTFM. Why go to a third party if the primary source is sufficient? You only risk adding confusion.

On the other hand, questions are often raised in a forum like this because the model the manual and/or software encourage is broken. One could argue the printf model is broken and there is no good way to fix it. Given the myriad of printf implementations (including most C inspired languages), its literally impossible to change the printf model. It's also impractical to re-write all the manuals to provide users with a more accurate mental model to understand printf. So RTFM might help the questioner solve there immediate problem, but does nothing to fix the deeper issue. At the vary least, an answer would need to say something like:

That wasn't how printf was designed. RTFM.

But ideally, the answer would provide a correct mental model and the answer to the immediate question, which is usually a link to the manual.

Answer 10

I'm an applied communications (technical writing) minor, so let me share something that a professor told the class, paraphrased.

People don't read the manual because the manual isn't pleasant to read. It's a chore - the font is small, the wording is complex and technical, and the design is poor.

I think the goal is to make both the product and manual accessible to the user. Not only should the product be easy and natural to use, but the manual should be the same. I think it should be difficult for the user to get stuck, but when it happens, the manual needs to actually help.

Answer 11

My major gripe with "RTFM" is that all too often my question could be restated as "WTFM" ("Where's The F___ Manual?").

Answer 12

If "RTFM" is coming up often enough, chances are the person asking the question didn't ask it the smart way. If a question smacks of a lack of effort or should have been obvious with a modicum of effort then going to a forum or begging others for help is, in effect, foisting off the work on them. It's analogous to the situation described here:

Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

It's not directly comparable, but the parallel should be obvious. People answering questions can be assumed to have a fixed amount of time, if they blow it all rewriting something from the manual or other easily available source then they can't answer intelligent questions from people who have done their research and are in a genuine quandary. "RTFM" is the nicest possible response there, the only alternative that makes sense is not answering at all.

Answer 13

RTFM is a valid response in the cases where the M actually describes in a way the user can understand what the system does, how to make it do that and whether the unexpected behaviour the user is experiencing is good unexpected (i.e. trapped errors) or bad unexpected (i.e. BSOD).

The issues with printf is one thing, but too often with technical documentation the manual just isn't worth reading, if it even exists (see also Code Comments ;).

But if decent technical docs exist that actually assist the user, i.e. train the user to respond with 2nd (let alone 3rd/4th level support) questions, rather than FAQs and common gotchas, then RTFM is a responsibility, not a cop-out.

Answer 14

RTFM is a modern-day version of the "Give a man a fish..." parable. It needs to be used correctly, for instance, if someone was to ask about printf's width usage, they should read the manual (man page, spec, K&R), it's there, it's clear. If someone asks a really challenging question like many here on StackOverflow whose answer is not so obvious and the location of said answer is not well known, then it's just inappropriate. It's a tool, and any tool can be misused.

Answer 15

"RTFM" came from a time that there were manuals that were comprehensive, well-organized, and above all else, useful. Nowadays, rather than manuals per se, there may be a set of books considered more or less standard references that may or may not be available to the person asking the question. Often, documentation devolves to modern-day folklore, passed blog-to-blog rather than orally, and indexed only by Google.

Answer 16

In general, it depends. :-)

For one thing, it depends on how the question is asked. The SO FAQ mentions something similar (show people you've done your homework).

I don't believe I've explicitly answered a question with "RTFM". However, I have occasionally told people to "Google it", but that happens only after they ask a question in response to my answer. For example, if Tim asks me how to avoid SQL injection vulnerabilities in his .NET application, I tell him to use SQL parameters, which are prefixed with the @ symbol in T-SQL/SQL Server/variations that I know of, and the Parameters collection in the SQLCommand he's using. Subsequent questions about the SQL parameters get a "Google it". If I'm really busy, I'd just say "SQL parameters. Google it.", which isn't as helpful, but it contains a somewhat useful pointer. While typing this answer, I realized that the first result on Google for "SQL Injection .NET" says the same thing, and then some.

But still, I try to be helpful when I tell someone to "Google it" by giving them something precise to look up. I might even Google it myself, and link to a couple of results that look promising. It helps me make sure I'm not wrong (that it is findable via Google), and makes a stronger statement ("See, it is really easy to find your answer!").

Answer 17

You should only tell someone to RTFM (Read The Fine Manual) when it is clear that they haven't done so. Not to make the problem go away, but because both parties need facts, not opinion to start a useful discussion and solve the problem. If someone quotes something he/she thinks is unclear in the documentation after reading it, make sure you help. Show that you appreciate people who do prior research. It should pay off.

Telling a user to RTFM isn't blaming the user. It's just a way of saying "First get your facts straight, then come back here if you have further questions."
Also, quoting excerpts from a manual really helps on phrasing a good informal question, and you are likely to be taken far more seriously. Experience tells me that most programmers see this as a good trait, not a weakness.

Note, the above goes for **community help where support costs 0,-. You would never tell a paying customer to RTFM, by obvious reasons. Or if you do, try at least to be diplomatic.

Answer 18

RTFM only exists because there are too many (usually) elitists out there that not only aren't kind enough to help people with questions - but also aren't capable of allowing someone else who cares to potentially respond to the question.

The argument that "they haven't already read the manual" is the usual reasoning behind this statement, but I've yet to find a reason why that matters. Sometimes people just want to talk to people about how things work, and if there's someone around that doesn't mind explaining it than that should be fine.

RTFM is not just counter-productive, but also ignorant - because anyone who says it (usually thinking that they're in the right) is basically implying that nobody here wants to answer the question - instead of ignoring the question completely. Ignoring the question is the best thing in that case.

"If you don't have anything nice to say, then don't say anything."