In this chapter
We'll learn how professionals find answers on their own — reading the error message first, going to official documentation, searching well, judging Stack Overflow and AI answers, and researching on GitHub — explained as a detective choosing which witnesses to trust.
The Problem in Real Life
John gives Anna a small challenge. The date library BlueTicket uses prints a warning after an update: "DeprecationWarning: format() with 'YYYY' tokens is deprecated, use 'yyyy'." "Find out what it means and fix it — without asking anyone. Tell me afterwards which sources you used, in which order."
Her first instinct is to search for "date library warning". Then she stops, and does what she now always does first: she reads the message properly.
Docs first, search second.
John
Searching Randomly vs. Going to the Best Source First
The answer is often already on screen
Error messages and warnings frequently say exactly what's wrong and how to fix it.
Search results vary in quality
Old answers, wrong versions and confident mistakes sit next to good answers.
Answers go out of date
A fix from 2019 may not apply to this year's version of a library.
Finding Answers: Error Messages, Documentation, Search and Research
The detective analogy: a detective has many possible witnesses. The person who was there (the error message), the official records (documentation), neighbours who heard something (Stack Overflow, blogs), and people who remember a similar case (GitHub issues). A good detective checks the most reliable sources first, notes when each story is from, and never believes a single witness without checking.
- 1. Read the error message — the eyewitness: read the whole message slowly (Act 17): the type, the description, the file and line, and any suggestion. Many messages literally tell you the fix — this one says "use 'yyyy'". Read the stack trace for the first line of your own code.
- 2. Official documentation — the official records: the library's or tool's own documentation is the most reliable source, and it matches the version you use. Look for: the getting-started guide, the API reference, the migration guide or upgrade notes (for anything that changed between versions), and the FAQ. For APIs, the provider's docs (Act 23).
- 3. Release notes and changelogs — what changed: after an update, read the release notes for the version you moved to (Act 18). Deprecations and breaking changes are listed there, usually with how to update your code.
- 4. Search well — asking the neighbours: copy the key part of the error message in quotes; remove your own file names, IDs and values; add the library name and version:
"format() with 'YYYY' tokens is deprecated" date-fns 3. Prefer recent results. - 5. Judging Stack Overflow and blogs — is this neighbour reliable? check the date and the version the answer is about; read the comments (they often say "this no longer works in v3"); prefer answers that explain why. Understand an answer before copying it — never paste code you can't explain (Act 16's AI rule applies here too).
- 6. GitHub research — similar cases: search the library's GitHub issues (open and closed) for the error text — someone may have hit it already, with a maintainer's answer. Read the source code of the function if the docs aren't clear; good libraries are readable.
- 7. AI assistants — a fast but unreliable witness: good for explaining an error or summarising docs, but they can be confidently wrong, especially about versions. Check what they say against the official docs (Act 16).
| Source | Detective version | Good for | Watch out for |
|---|---|---|---|
| Error message | The eyewitness | Exactly what went wrong here | Not reading all of it |
| Official docs | Official records | Correct usage for your version | Reading docs for the wrong version |
| Release notes / migration guide | The record of changes | What changed in an update | Skipping them |
| GitHub issues / source | Similar past cases | Known bugs and workarounds | Closed issues for old versions |
| Stack Overflow / blogs | Neighbours' stories | Common problems, explanations | Old answers, wrong versions |
| AI assistants | A fast, confident guesser | Explanations, first ideas | Confident mistakes |
| Instead of | Search for |
|---|---|
| date library warning | "format() with 'YYYY' tokens is deprecated" date-fns 3 |
| my test fails 1147.4999999999998 | javascript floating point money comparison |
| error in /Users/anna/blueticket/src/x.js line 42 | "Cannot read properties of undefined (reading 'map')" react |
Anna's path, in order: (1) the warning itself — it already suggests yyyy; (2) the library's migration guide for the version they moved to — it explains that YYYY means a "week-numbering year", which gives wrong results around New Year, and yyyy is the normal calendar year; (3) a quick search of GitHub issues confirms other people hit real bugs on 31 December. She changes the four places, adds a test for 31 December 2026, and writes a two-line summary for the team. Total: 15 minutes, no questions asked. John: "And you found a real bug that would have shown up on New Year's Eve. That's research."
Key Takeaway
Find answers like a detective, best sources first: read the whole error message (it often contains the fix), then the official documentation and migration guides for your version, then release notes. Search with the key error text in quotes plus the library and version. Judge Stack Overflow, blogs and AI answers by date, version and explanation, and understand before copying. GitHub issues and source code reveal what others already discovered.
Why This Matters
Nobody knows everything; professionals are simply good at finding out. Reading errors carefully, trusting official docs and judging other sources critically lets you solve most problems alone — and is exactly what interviewers mean by "how do you approach something you don't know?"
Fifteen minutes, no questions asked, one hidden bug found. Anna wants to keep getting better like this — not just for this Act, but for the rest of her career. John shares the habits that keep engineers learning long after the training ends.