It’s Time to Retire “RTFM”
Let’s Try These Compassionate Alternatives Instead
Latest version of this post: https://compassionatecoding.com/blog/2019/4/17/its-time-to-retire-rtfm
The culture of programmers and other technologists is plagued by toxic elitism. One of the manifestations of this elitism is an unrelenting hostility toward so-called “non-technical” people (a distinction that’s also ready for retirement), beginners, and ultimately anyone asking for help.
If you’re unconvinced, please spend a few minutes browsing the popular¹ question-and-answer site, Stack Overflow² (just make sure you prepare yourself emotionally beforehand).
One example of this hostility is the popular acronym “RTFM.” If you’ve never heard the term RTFM, consider yourself lucky. It stands for “Read the F***ing Manual.”³
Lovely, right? It’s often used to respond to questions when the respondent believes the asker could have found the answer “easily” in a technical manual or, more broadly, through other research.
When you use RTFM, you’re saying, “Not only am I not going to help you, but I also want to make sure that you feel ashamed about your inability to help yourself.”
If we want to create more effective teams and a more inclusive tech industry, we need to retire RTFM and the associated sentiment from our culture.
I wish it were obvious to everyone that this acronym is unkind and counterproductive, but when I tweeted about it, I received some objections that indicated that a deeper exploration may help.
Compassion will be our guide as we walk through the problems with RTFM, the reasons you might think you need to use it, and what you can do instead to create a more inclusive and productive tech industry.
Notes on Terminology
It’s more than just RTFM
RTFM is one of the more blatantly rude examples of hostility toward people asking for help, but it’s certainly not the only one. “Just look it up” and “Google it” are examples of milder, but also problematic variations. There’s even the entire website letmegooglethatforyou.com. In this article, I’ll use RTFM as shorthand for any of these declarative variations of the expression.
Compassion is not politeness
I mentioned that compassion will be our guide, so I want to clarify its meaning: Compassion is not the same as politeness or good manners; compassion involves understanding suffering in ourselves and in others and actively desiring to alleviate it.
Another way of looking at it is that compassion presents an optimization problem: minimize suffering. If we’re not building technology with an eye toward minimizing suffering, what’s the point?
Compassion often demands candid and direct communication, so being “fake nice” is not compassionate.
So, what’s wrong with RTFM?
Problem 1: It is devoid of empathy.
When someone comes to you with a question, that human being is experiencing some form of suffering. Perhaps it is extreme suffering in the form of frustration, confusion, or fear. Perhaps it is mild suffering stemming from the desire to satisfy curiosity. In any case, there is some level of suffering.
RTFM does nothing to acknowledge this suffering. It is therefore a rather callous response to people who come to you and expose their vulnerability by asking a question.
Problem 2: It assumes negative intent.
When someone asks you a question, how can you be certain that the person hasn’t already read the manual (or other documentation)? How do you know that the person hasn’t done extensive research before approaching you for help?
You may say, “I know this answer is found easily on the web, so there’s no way she did a web search.” What if the documentation has changed since you last checked or what if the web page you’re thinking of is no longer available?
Also, how do you know that the asker even knows what to research? Remember that you are a different person who has had different training and experiences from the asker.
As Brittany Storoz observed in her talk on error handling at Rocky Mountain Ruby, “Figuring out how to Google things is actually really hard.” She presented this example from a Ruby on Rails application.
She explained that it could be difficult for a junior developer to know which parts are relevant to include in a web search, and which parts are specific to our application.
One time an intern asked me, “How do I get all the text on these web pages?” For a moment, I thought, “There’s a ton of information on web scrapers online. Why is this kid asking me such a basic question?” Did I respond with “RTFM” or a link to Let Me Google That For You? No!
I asked, “Would a web scraper help with that?”
And he said, “Oh! Is that what it’s called?” He then proceeded to help himself. When he came to me, he wasn’t being lazy; he didn’t even know what to research. Perhaps he could have found it through other searches, but it took a 2-minute chat for me to point him in the right direction.⁴
RTFM makes the assumption that the person is motivated by laziness or perhaps even a desire to waste your time. It leaves no space for understanding the person’s true motivation in coming to you for help or even what they’ve tried so far.
Problem 3: It promotes shame.
The implication of RTFM is that the asker could have found the answer to the question without asking, and is therefore violating some social law by asking. This can easily stir a sense of shame in the asker.
Shame is such a painful feeling; it is cruel to knowingly encourage it in others.
In addition, negative emotions like shame are distracting, and they shut down our creative ability to solve problems.
Problem 4: It discourages learning.
Usage of RTFM discourages learning in a number of different ways.
First, it makes the asker afraid. Fear may stop the person from asking questions in the future, even questions that you might find appropriate to ask. Since asking questions is a great way of learning, your use of RTFM may hamper this individual’s learning.
Second, since you’re not taking the time to show someone how to benefit from reading the manual or doing web research, etc., the person won’t improve in that meta-skill of research, either, which means they’ll continue struggling in the future.
Third, it actually prevents you from learning, too. It cuts off further communication, which keeps you from thinking about potential gaps in your organization’s documentation, for example.
It also robs you of an opportunity to explain a concept or a research method to someone, which would help you grow your teaching and mentoring skills.
As I’ve written previously, “The evidence of true mastery of a concept is being able to explain the concept in simple terms to someone less experienced.” Helping others allows you to develop that mastery.
Problem 5: It’s inefficient.
Until a few years ago, I had internalized the idea of “RTFM” so deeply that I was terrified to ask for help. I would spend hours—days, even—doing independent research to solve a problem.
I was so scared of being seen as weak for asking for help that I was ready to do anything to avoid it. I felt particular pressure as a woman in tech not to confirm negative stereotypes about my group.
My stubborn insistence on figuring out everything by myself was terribly inefficient! There were many occasions when I was starting a new job or working through a tutorial online when it would have saved me so much time to just ask another human being for help.
As Marie Kondo writes in The Life-Changing Magic of Tidying Up,
“It is far quicker to ask a pro for the answer than to struggle to find one in the manual by yourself.”
My hope is that we can create environments where everyone feels comfortable reaching out for help.
OK, OK, but what about…?
Hopefully at this point, you’re willing to admit that RTFM can be harmful. But maybe you still think that in some cases, it’s acceptable. Let’s look at some common defenses of RTFM, and the compassionate alternative in each case.
Defense 1: “Engineers should be able to help themselves.”
Perhaps you use RTFM because engineers should be able to help themselves. After all, you figure out your problems on your own, so others should have to as well.
This position is consistent with this message tweeted in defense of RTFM (I added the bolding):
“Programmers ought to learn…certain habits of inquiry…”
“Your *first* inquiry should indicate…”
“Everyone ought to…”
“Should” and “ought” typically indicate a judgmental, and thus unkind, statement. As Marshall Rosenberg writes in Nonviolent Communication, these words are closely tied to feelings of “guilt, duty, or obligation.” So, the fact that a rationale uses “should” or “ought” is reason enough to reconsider.
If this is your rationale for using RTFM, ask yourself — why do I feel that I’m in a position to decide what others “should” be doing? Each person is responsible for his or her own actions. Your expectations of how another person ought to behave is not sufficient justification for responding to a question with rudeness.
The Compassionate Alternative
If your only motivation is upholding your sense of what the world “should” look like, then consider saying nothing at all in response to the asker. This is particularly appropriate if the question was asked to a group of people. You do not need to weigh in.
If silence is not an option, simply explain that you’re not the best person to help with the problem. This is an honest response because your attitude is clearly not conducive to helping.
Either saying nothing or admitting your inability to help is more compassionate than a response of “RTFM,” which would only lead to more suffering in the asker, who would likely feel dismissed and ashamed.
Defense 2: “I want this engineer to develop stronger problem-solving skills.”
Now let’s suppose you consider yourself a mentor to the asker and genuinely feel that it is in the person’s best interest to learn to look up information and troubleshoot problems independently.
This position is nicely illustrated by one response to the suggestion that we stop using RTFM:
“a great way to know how to fix something in future is to fix it, not be told how to fix it :/“
This defense of RTFM is an example of the false dilemma fallacy, i.e. that there are only two options: some version of RTFM and being told how to fix something.
Thankfully that is not the case!
I fully agree that independent problem-solving is a useful skill, and that as a mentor, one is in a great position to help a mentee develop that skill. What I find problematic is using RTFM as the method of doing that.
At the most basic level, each person is driven by the desire to avoid suffering. If a person is coming to you for help, this individual clearly feels that approaching you for help will lead to less suffering than continuing to work on the problem independently.
Now one option is to convince the person that asking you for help is so painful that they will try anything else, including continuing fruitless independent research. You can do this with “RTFM” or any of its variations, which will lead the asker to feel the extreme pain of shame for having asked a question.
The Compassionate Alternative
The compassionate alternative is to make the independent problem-solving less painful. The best way to do that is to help the person develop the relevant skills.
“That’s what I’m doing by saying RTFM!” you may protest. However, consider how professional teachers instruct students in new skills.
Does a teacher answer questions with “Read the F***ing Textbook”? One would hope not.
Instead of manipulating the person into wanting to improve research and problem-solving skills, why not explain your reasoning directly? “I understand you are frustrated by this problem. I don’t want to give you the answer directly because I’ve found that people learn better when they figure out problems on their own. In this case, if I were you, I might start by checking the documentation for X. I also would probably try a web search for Y.”
You can also ask questions:
“What have you tried so far?”
“Have you considered X?”
“What do the docs have to say about Y?”
Do you see the difference? You’re providing pointers to help the person develop the skills that will make independent problem-solving less painful without resorting to insults or manipulation.
Defense 3: “It’s not my job to help this person.”
You may feel that it’s not your job to help the person asking the question. In this case, you may feel RTFM is appropriate.
The Compassionate Alternative
Your responsibility to a person depends on your relationship to the person and on your value system.
If the asker is a coworker, then there’s a reasonable argument to be made that it is part of your job to help the person. Consider this point from Ron Jeffries’s The Nature of Software Development:
“A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.”
Mentoring and helping is part of your job. Additionally, it’s worth noting that face-to-face knowledge-sharing can be wonderful for bonding on a team. Consider the steps in the Compassionate Alternative section of Defense 2.
What if the asker is not a coworker? Maybe it’s someone in chat room or other community. In that case, your responsibility to help this person depends on your own values. Do you care about creating a compassionate, inclusive tech industry that welcomes newcomers? If so, then perhaps your value system compels you to help this person, and you can also benefit from the steps mentioned in the Compassionate Alternative section Defense 2.
If you look within to your core values and maintain that it is not your job to help this person, RTFM is still not an appropriate response. As with Defense 1, the Compassionate Alternative here is to stay silent or explain that you are not the best person to help.
Defense 4: “The asker isn’t showing enough empathy.”
You may believe that certain questions demonstrate a lack of empathy on the part of the asker. For example, you may believe that the person asking isn’t respecting your time.
For some reason, there is a bias toward protecting the more senior “elite” members of the tech community. I often see references to “How To Ask Questions The Smart Way,” a document full of demeaning language that shares examples of “stupid questions,” makes justifications of rude behavior, and expresses sentiments like, “RTFM is…justified when replying to someone who is just a lazy slob…”
A recent article supposedly about “Engineering Empathy” references that document and adds:
My number one pet peeve is Help Vampires. These are people who refuse to take the time to ask coherent, specific questions and really aren’t interested in having their questions answered so much as getting someone else to do their work. They ask the same, tired questions over and over again without really retaining information or thinking critically. It’s question, answer, question, answer, question, answer, ad infinitum.
This is often a hard-earned lesson for junior engineers, but it’s an important one: when you ask a question, you’re not entitled to an answer, you earn the answer. Hasty sounding questions get hasty answers. As engineers, we should not operate like a tech support hotline that Grandma calls when her internet stops working. We need to put in a higher level of effort. We need to apply our technical and problem-solving aptitude as engineers
Let’s unpack this. Calling people “vampires” is not the best path to building empathy. This attitude assumes negative intent. Words like “should” and “need” here are reminiscent of Defense 1.
I also can’t include this quote without pointing out that using “Grandma” as an example of someone who’s not tech savvy demonstrates a serious lack of empathy for women and elders, which is especially alarming in an industry plagued by sexism and ageism.
I do have compassion for the technologists who would like to feel more empathy from people asking for help. They’re human beings who want to feel respected. That is a valid way to feel. They are indeed as deserving as empathy as anyone asking for help.
However, rudeness is still not an appropriate response.
The Compassionate Alternative
It may help to consider the power dynamics here. While it’s great for everyone to show empathy to everyone else, when a person is asking for help, they are almost always in a position of less power. The asker may be more junior or newer to a company or even unemployed, so the asker is almost always in the more vulnerable position. Therefore, while it is important for the asker to empathize with the respondent, it is at least as important for the respondent, who holds more power and often has greater freedom, to empathize with the asker.
However, this doesn’t mean that the respondent needs to tolerate behavior that feels disrespectful. In a Slack community, I once helped a stranger with a Ruby question because she seemed desperate, and I had some time to spare. Then she started asking me a lot of questions, and I realized that it wouldn’t be sustainable for me to continue the relationship. So I simply told her, “I don’t have the bandwidth for this right now, but here are some communities where you can find help.”
I knew my limits and I set boundaries clearly but compassionately.
I actually find the need to do this all the time. I do quite a bit of pro bono mentoring for women, people from other underrepresented groups in tech, and people facing financial hardship. I don’t berate people for asking me for help; I just set boundaries on when and how often I do it so that I don’t overextend myself.
Sometimes people who maintain open source software or answer questions on Stack Overflow like to use the fact they are volunteers to excuse rude behavior.
It’s important to remember that we are always in control of our choices. If you can’t hide your resentment while volunteering, remember that you can always stop volunteering or clearly and calmly communicate boundaries.
RTFM is not a way to communicate those boundaries, and neither is shaming people by calling them “vampires.”
Setting boundaries might look like this:
“I volunteer my time helping here, and in order for me to feel comfortable helping you, I need to understand that you’ve spent X amount of time trying to solve this independently.”
That way, you set boundaries without being rude or implying that your preferences are the law.
If there are community rules that apply, you can also share those compassionately. “As this page explains, our community expects that questions include X, Y, and Z. Could you add those?”
Setting boundaries is an important element of self-care. It will help keep you from burning out, which will also help you behave more compassionately toward others.
Also, even if there are people out there with negative intent trying to get you to do their work for them, as Derek Sivers advises in Anything You Want,
Resist the urge to punish everyone for one person’s mistake.
Just because one person—or even a handful of people—might be trying to take advantage of your help, that doesn’t mean you have to make the choice to treat everyone rudely.
A Final Request
When someone comes to you with a question that you think is “stupid” or “lazy,” please pause for a moment and consider what they might be feeling—and what you’re actually feeling.
Rather than responding with some version of RTFM—an expression that lacks empathy, assumes negative intent, encourages shame, prevents learning, and contributes to inefficiency—please consider these more compassionate alternatives:
- Silence
- Clearly communicating boundaries
- Asking follow-up questions
As Ryan Holiday writes in The Obstacle is the Way,
No harshness, no deprivation, no toil should interfere with our empathy toward others. Compassion is always an option.
With small changes like retiring RTFM, all of us can do our part to create a more compassionate, welcoming, productive tech community.
About the Author
April Wensel is the founder of Compassionate Coding, a conscious business on a mission to transform the tech industry by training technologists in emotional intelligence.
Footnotes
- At least among white males.
- The StackOverflow community technically discourages RTFM; however, you’ll notice their Ask help page links to this document, which encourages using RTFM. Also, as discussed throughout this article, this is part of more general practice of shaming, which happens frequently on StackOverflow.
- Yes, there are milder versions.
- I accept no responsibility for what he did with this knowledge. :-P
