Read The Source: Learning by Cutting Out The Middleman and RTFM

I wasted three hours last week fighting with a Strands hook that "wasn't working right." The tutorial said to do X, the Stack Overflow answer said to do Y, and my code was doing neither. Finally, in frustration, I asked Claude and it just directly looked in the module source code.

This keeps happening. We reach for the filtered interpretation - the blog post, the video tutorial, the Medium article - when the actual source is sitting right there, written by people who understand it deeply and have every incentive to teach it clearly.

The Tutorial Tax

Here's the thing about most technical tutorials: they're written by someone who just learned the thing themselves. They're filtering their incomplete understanding through their specific use case, adding their own interpretations, and often getting crucial details wrong.

The academic equivalent is even worse. Someone writes a groundbreaking paper on transformer architecture. It's freely available, written by the researchers themselves, with all the context and reasoning. But instead of reading that 12-page paper, we watch a 10-minute YouTube video where someone who read the paper explains it to us, adding their own confusion along the way.

We're learning through telephone. Every degree of separation adds noise and removes signal.

Working Backwards to Primary Sources

So I think one of the advantages of using Claude is that it can read the source code directly.

Find the primary source:

• OAuth 2.0 spec from the IETF (the people who designed it)
• GitHub's OAuth documentation (the people who implemented it)
• The library source code!

Skip everything else initially: If you see a tutorial, use that as a signal of what source code and documentation to read. Those come later if I need specific implementation examples, but they're supplements, not starting points.

This approach feels harder at first. Specs and official docs are dense. They're comprehensive. They assume a certain level of knowledge. But here's what I've learned over 25 years: that initial difficulty saves exponential time later.

The spec tells me why things work the way they do. The official docs tell me the intended use case. The source code shows me exactly what's happening. When I hit a problem, I know where to look because I understand the foundation.

The RTFM Renaissance

"Read The Fucking Manual" got a bad reputation. It became a dismissive way to shut down questions. But the underlying principle is sound: the manual exists for a reason.

Modern documentation is often excellent. The Rust book is a masterclass in teaching a complex language. The Anthropic API documentation (yes, I work with Claude a lot) is clear about capabilities and limitations.

These aren't dusty PDF manuals written by technical writers who never used the product. These are living documents, maintained by the teams building the tools, updated constantly, with examples and explanations written for developers like us.

When the Nuxt team releases a new feature, they document it. When the Vue team changes reactivity behavior, they explain why. When a library author adds a method, they describe the use case. This is first-hand knowledge from the people who made the decisions.

Compare that to a blog post from twelve months ago that might be outdated, might have misunderstood the feature, and definitely doesn't have the context of why things are designed that way.

The Three-Tier Source Hierarchy

Not all sources are equal. When I need to learn something, I work through this hierarchy:

Tier 1 - The Creators: Official documentation, academic papers from the researchers, technical specifications from the standards bodies, source code comments from the library authors. This is as close as you can get to understanding the original intent.

Tier 2 - Curated Interpretation: Official tutorials, first-party examples, documentation from the team that built it. Still authoritative, but one step removed from the core design decisions.

Tier 3 - Community Knowledge: Blog posts, Stack Overflow answers, third-party tutorials, YouTube videos. Useful for specific problems and alternative perspectives, but never the starting point.

The pattern: start at Tier 1, drop to Tier 2 for practical examples, only hit Tier 3 when you need to see how others solved specific edge cases.

What This Looks Like in Practice

I wanted to understand how MCP (Model Context Protocol) works. The pattern:

1. Read the specification written by Anthropic who designed it
2. Study the TypeScript SDK source code to see the actual implementation
3. Look at official example servers to see intended patterns
4. Only then look at community implementations to see creative approaches

Another example: when TypeScript 5.0 added decorators, I didn't search for "TypeScript decorators tutorial." I read the TypeScript release notes, read the decorator proposal, and looked at the test cases in the TypeScript repo. Done. No confusion about which decorator syntax, no outdated patterns, no wondering if the tutorial is correct.

The Compound Effect

This approach compounds. When you learn from primary sources, you build a mental model of how things actually work. The next time you encounter that library, framework, or pattern, you understand it at a deeper level.

You also get better at reading dense technical material. Specs become easier. Academic papers become approachable. Source code becomes readable. These are skills that multiply across every technology you touch.

And crucially: you learn to trust yourself. You don't need someone to interpret the documentation for you. You can read it, understand it, and implement it directly. That independence is worth far more than saving an hour on a tutorial.

When to Break the Rule

I'm not absolutist about this. Sometimes you need a tutorial. Sometimes a blog post explains the context that makes everything click. Sometimes a Stack Overflow answer saves hours of debugging.

But those should be supplements to primary sources, not replacements for them. Read the docs first, then find the tutorial that fills in your specific gap. Read the paper first, then watch the explainer video. Understand the source first, then see how others applied it.

The Bottom Line

This is the pattern I keep coming back to: learn from the people closest to the source. The library authors want you to succeed. The researchers want you to understand. The spec writers want you to implement correctly.

They've done the work of distilling complex topics into documentation. They've anticipated your questions, provided examples, and likely explained the reasoning.

All we have to do is read it.

Next time you're about to search for a tutorial, try this instead: open the official docs. Read the getting started guide. Look at the API reference. Read the source code if you need to. Give the people who built the thing a chance to teach it to you directly.

You might be surprised how much clearer everything becomes when you cut out the middleman.