RTFM: The People Who Actually Did, and What They Got Out of It

There's an old acronym from the early internet era that you probably still recognize: RTFM. Read the freaking manual. It was sarcasm, mostly — a way of telling someone they'd asked a dumb question with an obvious answer. The joke was that the manual existed, that someone had written it, and that almost nobody was going to touch it.

Decades later, the acronym aged into irony. We don't even have manuals anymore, not really. We have tooltips. We have onboarding carousels that disappear after five seconds. We have YouTube tutorials shot in someone's basement with a ring light and a skip-ad button. The idea of sitting down with a 200-page document before using something — by choice, deliberately — has become so alien that it reads almost as a personality disorder.

But some people still do it. And they're worth paying attention to.

How Skipping the Manual Became a Flex

At some point, figuring things out without instructions became a marker of intelligence. The person who could unwrap a new device and have it running in four minutes — no box consulted, no guide opened — was the competent one. The person squinting at a diagram was the one who needed help.

Apple probably accelerated this more than anyone. The original iPhone shipped without a stylus and without a manual, and Steve Jobs treated both omissions as features. The device was supposed to be self-explanatory. Intuition was the interface. That philosophy spread outward into software design, product philosophy, and eventually into culture — if something needs explaining, the thing is broken, not the user.

Which sounds great, until you realize what it quietly cost us.

When products are designed purely around intuitive first contact, they tend to flatten. Features that require context get buried or cut. Depth gets traded for discoverability. The assumption that users won't read becomes a self-fulfilling design constraint, and over time, the products themselves get shallower to match.

What the Manual-Readers Actually Know

Spend any time in communities built around serious craft — woodworking, amateur radio, embedded systems, professional audio, darkroom photography — and you'll find people who treat documentation like source material. Not as a chore, but as the actual point of entry into a discipline.

Mark, a network engineer based in Portland who's been in the field for over twenty years, describes reading technical documentation as "the only way to actually know something versus just knowing how to use it." There's a difference, he says, between being able to operate a tool and understanding what it's doing. The manual is where that distinction lives.

That gap shows up in real ways. Someone who skimmed a tutorial can do the thing the tutorial showed them. Someone who read the documentation can debug when the thing breaks, adapt when the context changes, and combine the tool with other tools in ways the tutorial never covered. They're not just users — they're practitioners.

This isn't limited to tech. Cooks who actually read through a cookbook before cooking from it — not just recipe to recipe, but the introduction, the technique sections, the headnotes — consistently describe a different relationship with the food they make. Same with musicians who read theory texts rather than just learning songs by ear. The manual, in whatever form it takes, provides the grammar. The tutorials give you phrases. Grammar lets you build sentences you've never seen before.

The Cultural Shift Nobody Named

We normalized skipping documentation so gradually that we never really named what we were giving up. Part of it is attention economics — who has time? — and that's fair. But part of it is something more ideological: a suspicion of slowness, a cultural allergic reaction to anything that looks like it might take a while.

We celebrate the person who figures it out fast. We don't really have a vocabulary for the person who figures it out fully. And the two aren't the same thing.

There's also something worth examining in who gets to claim the "I don't need the manual" identity. It often maps onto a certain kind of confidence — the kind that's frequently rewarded in tech culture specifically — that can shade into a resistance to being taught anything at all. Reading documentation is, in a sense, an act of intellectual humility. It's acknowledging that someone else understood this thing before you did, and that their effort to explain it is worth your time.

That posture doesn't always come naturally in spaces that prize moving fast and breaking things.

The Weird Pleasure of the Deep Read

Here's something the manual-readers will tell you that sounds strange until it doesn't: reading documentation is often genuinely interesting.

Not all of it. Plenty of it is dry and badly written and organized by someone who clearly knew the product too well to explain it to someone who didn't. But technical writing at its best is a specific kind of thinking made visible — someone who understood something deeply, working hard to transfer that understanding to a stranger. When it works, it's almost intimate.

User manuals for older electronics have developed a cult following for exactly this reason. The manuals for Nakamichi tape decks, old Roland synthesizers, vintage Leica cameras — people collect them, share scans online, read them for pleasure. They're artifacts of a time when the assumption was that the person buying the thing wanted to understand it, and the manufacturer's job was to make that possible.

Some of that culture is coming back, quietly. The open-source software world has always maintained strong documentation traditions, and there's been a noticeable uptick in projects that treat their docs as a first-class product — not an afterthought. Communities like Obsidian, Vim, and various Linux distributions have entire subcultures built around people who went deep on the docs and came out the other side knowing something most users don't.

What You're Actually Opting Out Of

None of this is an argument for reading every manual for every product you own. That would be exhausting and mostly pointless — you don't need to read the documentation for your blender.

But for the things that matter? The tools you use to make your living, the instruments you're trying to learn, the software systems your work depends on? Skipping the manual isn't neutral. It's a choice to stay on the surface, and surfaces are where everyone else is already standing.

The people who still read the documentation aren't doing it because they're slow or because they lack confidence. They're doing it because they've noticed something: the people who went deep know things that the people who went fast don't. And in almost every field, the people who know things have more options than the people who can only operate them.

RTFM stopped being a joke somewhere along the way. Now it's closer to a competitive advantage — one that's sitting there, unclaimed, because everyone else decided it wasn't worth the time.