The Secret Origins of RTFM

By on 04/01/2015.


It’s 10:30AM. The blue, translucent Outlook mail notification wafts at the bottom of our fearless support guy’s screen.

“Hey! Sorry to bother you, but how do I….”

Our fearless admin’s eyes roll deep into the back of his eye sockets as he emits a loud, exasperated sigh. He knows it’s in the manual – he helped write it. But no one seems to read it. He feels his efforts have been wasted.

But today, our fearless admin has a plan. Through the miracles of modern science and some quick Google searches, he has found a secret formula that would merge his mind into anyone that emails him to ask questions. They would be under his control and would instantly think to look for the answers themselves. All he needs is a bolt of lightning to complete the transformation …

The above scenario is one of the most contentious parts of anyone’s job in IT. We lament over and over about how no one reads anymore, but we are also often just as guilty. Victims of our own hubris and overconfidence. In our own minds, we’re somehow annoyed by the very job we were hired to do. Help people solve problems. But sometimes it just touches the nerve, especially in situations where you’ve already explained how to fix it, and even more especially when you’ve already explained how to fix it to the same person.

It’s a slippery slope. Of course you always want to help, but at the same time, if you’re always there and available, it will lead to a condition where the user/junior admin will always skip the steps and just come straight to you.

There is no shame in reading. However, roughly 75% of IT is comprised of men. And it’s a pretty common perception that men don’t read (or ask for) directions.

There are some important things to keep in mind when you run into something you don’t know, aren’t sure of, or are simply installing/setting up for the first time.


Seriously. Read the instructions. Unless your purpose is to test what happens when people don’t read the instructions. Even if you’ve done whatever you’re trying to do 100 times prior, read them anyway. Or at least keep them close by for reference. There is no way to document every scenario that any given admin will run into, because every environment is set up in a unique way, and every department has different procedures in place. At NetApp, we publish two sets of instructions:

  • Installation & Administration Guide – This is more akin to typical step by step stereo instructions, and should be treated as such to get your environment up and running.  But to truly tailor your kit, we have the …
  • Best Practices Technical Reports – Once the initial configurations are in place, these are the religious gospel works to truly tailor your stuff to your environment, and take advantage of all of the little tunables and nerd knobs.  It could also be titled, “How to Get the Biggest Bang for your Buck!”

Shameless plug for NetApp NFS/multi-protocol NAS-specific technical reports I wrote: 

TR-4073: Secure Unified Authentication

TR-4063: pNFS Best Practices

TR-4067: NFS Best Practices and Implementation Guide

TR-4379: Name Services Best Practices

2) Use your search skills

In the industry, we call this “Google-Fu”

…and say nerdy stuff like “The Google-Fu is strong with this one…” in reference to those that are good at searching.

There is a very good chance someone else has asked the same exact question you have asked and it’s been answered, or will at least put you on the right track. There are even dedicated websites such as Quora, StackOverflow, and even reddit designed specifically around the Q&A style! If you spend 20 minutes searching and don’t find your answer, it doesn’t mean it hasn’t been answered, but more likely that the person posting it doesn’t understand search keyword optimization, or that it’s buried in some deep obscure location. You will also, often times, stumble across answers to related questions that you may not have even known were problems.

Flex your Google-Fu daily. It will become your deadliest weapon as an admin.

3) “Search. Read. Ask.”

In most circles, it’s considered a bit rude and inconsiderate to blindly ask how to fix a problem that you’re not sure how to even describe. Most don’t even take their cars to the mechanic anymore without at least googling to find out what that clicking noise might be under the hood, and if anyone else has heard it and has a quick fix.

Don’t ask first. For one, if you ask before searching or reading, you’ll probably ask an uninformed question that will require a long chain of dialogue just to get to the point, and that might take longer to accomplish than if you had just read in the first place. If you search and read first, you might never need to ask.

Also, keep in mind the lesson of #2: There is a very good chance someone else has asked the same exact question you have asked. That means it’s likely it’s been documented somewhere already.

You could also slightly modify the order to “Read. Search. Ask.” That will help make your search more intelligent. There is an insurmountable level of content on the WWW for you to read, listen, and subscribe to, on just about any topic that you could imagine. There are podcasts on beard grooming, barrel charring for scotch whiskey, and yes… even a podcast on NetApp.

Embrace and immerse yourself in these communities, and before long, you will be answering not only your own questions yourself, but sharing those answers with others in the form of discussion threads and your own blog that you’ll likely start to keep track of all of these questions that you’ve answered! Ask any blogger… a large majority of them will tell you that is how they started.

Don’t just be a consumer – be a contributor!

4) Remember why people write documentation.

They don’t write it for fun. They write it to guide their users and admins to take advantage of all of the benefits a particular system or platform has to offer, and to help people avoid needing to ask questions. Sure, there will always be corner cases that aren’t covered in docs, but I bet you would find that most cases have been heavily documented either in tech docs, knowledge base articles (KBs) or a blog/comment somewhere. If it’s still not clear after reading, reference where you looked and ask away. If nothing else, you may inadvertently strengthen your Google-Fu!

5) Practice what you preach.

Finally, if you’re telling someone to RTFM, you better be sure *you* actually read it, too. And if you read, and if you search, and you end up having to ask, pay it forward and be sure that a KB article is created or a blog post is written, because that is how the system works.

This is the IT circle of life. Hakuna matata. 

Of course you’re going to find situations where things are not documented, or need updating. It happens! But keeping things up to date and documented helps the next guy who has the same question, and was in the same situation as you when you first started searching.

Ultimately, reading helps make us all better at what we do, whether that’s via knowledge or comprehension. And it always ends up leading to more documentation for the next guy that comes along, making everyone’s lives that much better in the glorious and wonderful world of Information Technology.

Justin Parisi
Tech Mktg Engineer at NetApp
Justin is a Tech Marketing Engineer for all-things NFS around Data ONTAP at NetApp. He is a VMware vExpert, Cisco Champion, and a member of the NetApp A-Team. He also enjoys comic books, video games, photography, music, film, and current events/politics.