RTFM, Do Crime

In my travels through vintage tech over the years, I have had to track down a considerable amount of old user manuals. There was a time where the user manual was full of info junkie goodness, had everything you needed to get the most out of your product and more. Join me as I shake my fist at a passing cloud and complain that we just don't share knowledge very well these days.

I am speaking largely of user manuals in this article, as opposed to service manuals or video game manuals, both of which also hold a special place in my heart for different reasons. The user manual, however, had a focused mission, one that bridged the understanding gap between the engineer who designed the product and the end user. Simply put, Its purpose was to take the user from basic to intermediate operator, empowering the user with much more ownership over their product.

We've kinda lost that power, haven't we?

Back in the mid-90's, when my inner computer nerd was just starting to get his wings, RTFM culture still existed. We were beginning to see the impact the Internet was going to have on the publishing of user manuals as a whole, but even then you could still rely on most tech products coming with a fairly hefty booklet, at the very least. Prior to my time, many tech products came with schematics and service manuals, both of which had already become ephemera I did not discover until much later in life when I started working on tube radios and test equipment. Printed manuals were already on this same path in the 90's, being replaced by PDFs and videos, but still common enough to overlook their gradual disappearance from the consumer expectation despite many being resistant to these changes.

To their credit, designers were working to make the tech user experience more intuitive and accessible, which I applaud. Computers, for example, had the introduction of graphical interfaces, so a typical user could sit down, look at the screen for a little bit and probably have some idea about where to point and click or which button to press to accomplish a basic task. While the user could now typically get started quicker than ever before, there was some nuanced understanding lost with the absence of explicit information in exchange for an implied logic to be inherited by these design approaches when compared to the earlier "here's a command prompt, the world is now your oyster" approach taken by DOS and microcomputers like the Timex/Sinclair 1000. Naturally, people still had questions.

As noobs hit the tech scene more and more, the veteran techies leaned into gate-keeping, with cries of Read The Futzing Manual (kid-friendly version) on early message boards as inexperienced users wandered into their online hiding spots and wanted to know more. It happened to me countless times, I remember, with some of the gate-keepers going so far as to flame me for days after accidentally confusing the ANSI and ASCII acronyms. I never let that one go, I guess. All the jargon is still tough for me, although I feel I have gotten better. At least a lot of computer components are named by their function, as opposed to, say, bird names which seem to be based on hallucinations from tripping ornithologists instead of what the bird actually looked like.

In the defense of noobs that came after me, user manuals became less and less easy to get your hands on. I do not recall any sort of death knell for paper published user manuals, but there were certainly signs. David Pogue, celebrated author of a few helpful computer books, wrote an article for Scientific American (linked below) that explores this shift from paper to screen, but mentioned something I consider of key importance; structural literacy. Pogue defines this as the "art of knowing what to look for" when seeking assistance online. This is arguably where I often failed as a wee compooter enthusiast, finding my way on to some early hacker Usenet group and wanting to know how I could nab those sweet, sweet software cracks, only to be used as target practice for some of the most colorful language about wieners and butts that my high school eyes had seen. Still, in their own caveman way, those gate-keeping users were trying to teach me something important, something that I still see as a problem today; to ask a good question, you must do the homework first.

This was the essence of RTFM, meant to simultaneously improve the quality of information over time and keep out the lazy riffraff. Sure, it was also a tool of abuse for spiteful old men who forgot that someone at some point helped them get to where they are, but it is difficult to not let them overshadow the few good mentors in those communities. Still, the RTFM ethos prepared and encouraged us to ask better questions, should we choose to follow it. Rick Moen and Eric Raymonnd's HTML book How to Ask Questions The Smart Way (linked below) has undergone 10 revisions since its first publication in 2004, but the core concepts are unchanged, just as relevant now as they were back then. If you want to take anything away from that, the 7 steps in the "Before You Ask" section of the book are worth committing to habit.

The problem I started to run into, back in those early days, is that a basic manual was not always available, so doing the homework first was not necessarily an easy or obvious step. I recall my dad buying a portable air compressor (referred to as a "pancake compressor" in the US and possibly elsewhere?) that came with a Quick Start leaflet instead of a full fledged user's manual. At first I thought that quite convenient, having to read only about one and a half pages of material before understanding how to turn the thing on, plug in my airbrush gun and do my art class project (that one was Warcraft: Orcs & Humans themed!). In retrospect, I realize it offered nothing in terms of helping the user troubleshoot small issues they may encounter, or gave them any accessible idea about how the machine actually worked. The understanding gap was coming back again.

Having a basic idea of how a product is supposed to work is the key to being able to think critically about it. In my world, I see critical thinking as being able to assess, understand, and make logical inferences based on the facts at hand so a reasonable decision can be made about what to do next. This is the core of troubleshooting and I can say that with some authority, being a professional troubleshooter in my offline life. You cannot fix anything if you do not have a basic understanding of its functions, but more importantly, you cannot begin to ask useful questions either.

Generally speaking, when I am onsite to fix a machine, it takes about three minutes to realize the operator has never RTFM'd, and only knows how to make X do Y as they have been trained, despite the fact that my employer still ships product with both a physical and digital copy of the manual. The quality of our manuals could be better, so I won't try to dodge that. In fact, I'm on a side-quest to rewrite them to be much more robust and comprehensive. Still, on a weekly basis, I probably spend about 4 - 8 hours answering questions that are definitely answered in the provided manual. The crazy part is the operator probably never had an opportunity to look at the manual because their employer never provided it. As you can imagine, this level of information control is remarkably limiting and inefficient and the reason why machine operators in industrial settings are referred to as "button pushers" in the most derogatory way possible. These people are not given an opportunity to grow and they aren't even aware that they can, in some cases.

We do have to be careful with the RTFM model, though. It is a blunt instrument, but one to be wielded with some finesse. Rather than using it to shoo inexperienced users out of our respective tech silos, we can nudge them in the right direction, potentially fostering growth. I tend to take the following approach:

Noob: "How do I do a thing?"

Me: "I will not answer your question, but I will show you how you can answer it for yourself."

It's just that easy.

One of two things always happen with that approach. The first is the ideal outcome, where the person listens, approaches the provided reference material to learn some basic stuff, then either answers their own question or comes back with a more intelligent question. The second outcome is less ideal but still useful, seeing the person get frustrated after not being provided with an immediate answer and leaving. It still works as a health filter for the community, weeding out individuals would end up, in the long run, being more of a burden to the community than a contributing member. Teach someone to fish and all that, but if they just want the fish without the work, don't be afraid to leave them on the shore.

To explore the wrong way to use the RTFM cudgel, tech communities with crufty, imposing members standing at the gates often suffer a slow and agonizing death. I hold up ham radio as a fantastic example of this. Through and post World War II, ham radio was excessively popular in North America and beyond. In the decades since, the number of active operators started to dwindle. My own entry to the hobby was one of curiosity that was quickly stamped out by the constant walls-up attitude of the established members despite me both having studied and earning my license. I was in a position to ask reasonable questions, but was usual met with a sentiment that essentially amounted to "go figure it out."

We so easily forget who helped us along the way, especially when the journey was long and arduous. These same crank old hams also spent most of their on-air time complaining about the hobby dying when they weren't sharing all their health problems. They made for an unwelcoming, toxic environment and had the nerve to wonder why young people didn't want to come around. Funny, that.

Thankfully, ham radio is seeing a recent surge in fresh new members who are eager to experiment and share their knowledge. I partially blame Baofeng, a modern and cheap radio manufacturer, but there were certainly other factors in this sudden growth and perhaps I will explore that in a future editorial, but for now, it is sufficient to note that getting into the hobby is now more easy than ever because the documentation and the community makes itself very accessible.

And there it is. It starts with the manual, of course, but once that inexperienced user is aligned with the knowledge in those pages, integration with the community is nurtured. The whole process is driven by communication presented in an accessible way, communication that is often lost when we start to distance ourselves from our embarrassingly noobish origins.

Someone left a door open for you, right?