RTFM

As recently as a couple years ago, you could win by simply reading the (f’ing) manual. Earlier in my career I was chided with this trite remark, but I couldn’t deny its correctness. Later in my career, I gleefully did the chiding myself. The answer could not be uncovered with a Google search, there was no StackOverflow post tailored to the exact challenge you were having integrating with obscure system XYZ: You’d have to read the manual. Documentation, changelogs, API specifications, mailing lists, and, God forbid, Javadoc.

You could be paid thousands of dollars, millions even, to sit down and turn the technical jargon printed on the manual into a repeatable process that solved a customer’s problem. If you were a consultant you could buy software and have a nice, clean abstraction that sat on top of those pitiable piles of pitiable words. Building the software could be even more lucrative, if you could handle being at the mercy of mercurial APIs and changelogs. I didn’t mind, so I did just that: I built an integration platform with a few co-founders. We had fun, we made our customers happy, we made money, and eventually, we were acquired.

Our advantage, put simply, was that we were willing to read the manual. Whether there was a business problem that seemed out of scope for our product, an esoteric system that a customer couldn’t integrate with, or an operating system or firewall that gave our on-premises agent a fit, we’d always put in the hard yards to understand the challenge ahead. There were so many times where I wanted to give up, explain it away, and fire off ten technical reasons why we shouldn’t build something or accommodate a request. But when you finally capitulate, when you block off a few hours to understand a new domain and you actually read the documentation, the solution may be written plainly on the pages that stand before you.

If your competitors were not willing to do that and you were, you could have won by default. No one liked doing this work, least of all programmers. I have used the past tense here because now, I’m not so sure. There is still profit and plunder to be wringed from the margins of manuals, but it’s now being done by LLMs. They still make mistakes, of course, and you may be forced to read a paragraph or two in order to validate a hunch or confirm a suspicion. But reading documentation in its unabridged format would be considered an act of spite in July 2026.

Today, you are no longer fit for such a laborious task: The manuals are now increasingly written by machines, for machines. Under this new regime, you’ve been moved from the proverbial production floor to an office upstairs, where you now have but a vague input into the process and a ceremonial role in shepherding its output.

This little formula for winning I have stumbled upon may not hold up in a landscape utterly dominated by LLM-powered work products. At the very least, there are a ton of new variables. In my estimation, though, this human grit and determination built from powering through a problem will always be a factor in our success. Building that muscle is its own reward, and we don’t fully understand the consequences where the majority of people have let it atrophy beyond repair. I know it’s not practical anymore and it’s easier to just ask Claude, but if pride in your work and knowledge for its own sake are still to be valued then I must not relent: Read The (F’ing) Manual!