RTFM Is Losing Its Force — When the Cost of Reading the Docs Goes to Zero

In IT and coding there is a famous line, RTFM (Read The F***ing Manual)¹, half joke and half reproach: the answer is in the documentation, go and read it yourself.

The line itself is not wrong; many problems really can be solved by looking up the official docs. But for someone not yet familiar with that system, being told to go read the docs is often about as useful as no advice at all.

Why RTFM was always an empty line

#

The problem is that learning and getting familiar with the manual for a language or a system takes an enormous amount of time, the same as actually learning a foreign language or the culture of an unfamiliar country.

People who are more gifted, or who have already spent a long time becoming experts, can only tell you to RTFM, unless they are able to do the thing for you.

So what actually happens on the ground is this:

• You hit a problem and need an answer you can use in five minutes.
• The correct route is to read a document you will only ever use this once.
• So you don’t; you search, you ask someone, you copy-paste a snippet that looks like it works.
• And half a year later you often pay for it.

This is not laziness but a rational cost calculation, since paying foreign-language-level learning costs for a one-off need was never going to be worth it.

And this happens to be what AI is best at

#

Among humans, people who have read everything and remember it are rare, but that is exactly what AI is best at. It can essentially “recite” the syntax of every programming language, and it can look up the latest version differences at once, and version differences are precisely where human experts go stale fastest.

Most work settings do not specialise in one particular scenario, nor do they have high performance demands; what they need is a grasp of several common languages and the basic use of many systems.

For this broad-but-shallow, common-scenario kind of need, AI gives moderate, safe answers.

What really changed is feasibility, not speed

#

I marked this class as a hundredfold, but that number is misleading. The point is not that the same thing became a hundred times faster; it is that many tasks moved from not feasible in the short term to feasible in the short term.

The old judgement went like this: this feature needs a tool I don’t know, understanding it alone would take two weeks, forget it, work around it the crude way.

So the better solution never got adopted, not because it was rejected, but because it never even got evaluated.

When the cost of reading the docs drops from two weeks to ten minutes, those “forget it"s start turning back into “let’s try”, one by one. Where I save the most time is actually on the things I would never have done before.

Side effect: you don’t really come to understand it

#

Honestly, for tasks finished this way, my understanding of the tool is far below what it would be had I chewed through the docs myself. I know it works, I roughly know why it works, but I don’t have the overall picture you only get from reading the whole manual.

Most of the time that is a fair trade; I may only ever use that tool this once. But some tools you will use for the rest of your life, and those you have to read yourself.

If your team is stuck knowing there is a better way but nobody has time to learn that tool, that wall is a lot lower than it used to be.

What I do is get you over that wall →