Searching effectively

When local docs don't have it, you search — the web, Stack Overflow, an AI agent. All three give you candidate answers, not guaranteed ones. The skill is asking well, reading critically, and verifying before you commit. It's the same verify-don't-trust habit from the AI lesson, applied to every source.

Craft the query

Vague queries get vague results. A good search is specific:

• Include the exact error message (in quotes) — error text is highly unique.
• Name the language/tool and version — "python 3.13", not just "python".
• Describe the goal, not your broken attempt — "split string by multiple delimiters" beats "my split isn't working".

Often the most useful result is the official documentation itself; add the library name to bias toward it.

Judge the source

Not all answers are equal:

• Authority — official docs > the library's own issues/discussions > a reputable article > a random forum post.
• Recency — languages and libraries change. A confident 2016 answer may describe an API that no longer exists. Check the date.
• Fit — does it match your version and situation, or a different one?

On Stack Overflow, the accepted answer isn't always the best — scan the highly-voted alternatives and the comments, which often note "this is outdated" or "don't do this."

Always verify

This is the step people skip. Whatever the source — a blog, a top answer, an agent — confirm it against the official reference before relying on it:

• Does the function/option it uses actually exist in your version's docs?
• Do the arguments and return value match?
• Does it behave as claimed when you run it?

Where to go next

That completes the beginner Reading & Documentation module — you can find and verify answers from your machine, the official docs, and the wider web. The intermediate Documentation that lasts module flips it around: writing docs that others (and future-you) can rely on.