Search as a Skill
"My code no work react" finds nothing; "React stale closure useEffect interval" finds the answer in the first result. The query is a compressed statement of what you understand about the problem, and evaluating what comes back — authoritative, current, your version, explains why — is the second half of the skill.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Something is broken and you are about to search for it. What makes one query find the answer and another find nothing, and how do you decide which of the results to believe?
The store's admin dashboard shows a live order count that updates every few seconds — except it does not. It shows the first count forever. You have searched "react counter not updating", "react state not changing", and "setInterval react bug", and every result is either a beginner mistake you are not making or a library you are not using.
Type the symptom in the words you would use to a colleague, open the first five results, and look for a code block that resembles yours. When none matches, rephrase the symptom and try again — which feels like persistence.
Symptom words find symptom pages: forum posts by people who were as confused as you are now, answered by people guessing. The query contained no information the search engine could use to distinguish your problem from ten thousand others.
- Symptom words find symptom pages: forum posts by people who were as confused as you are now, answered by people guessing. The query contained no information the search engine could use to distinguish your problem from ten thousand others.
- The results that do match get pasted without the cause being understood, so the fix works until the next component with the same underlying mistake, which then has to be searched for again as though it were new.
- The search never converges because each rephrase is another set of symptom words. Persistence at the wrong level produces a longer history and no new information.
- When a result finally looks right, there is no way to tell whether it is right for your version, because the query never named a version and the result never did either.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat the query as a statement of what you know about the cause, not the symptom. Before searching, spend a few minutes turning "it does not update" into the mechanism you suspect: the interval was set up once, it calls a function that read the state when it was created, the state it read is the initial one. That is a stale closure, and the query is now "react useEffect setInterval stale closure" — every word a term of art that a good answer would have to use.
- If you cannot name the mechanism yet, search for the mechanism first: the concept — "how does useEffect capture state" — rather than the symptom. The concept search produces vocabulary; the vocabulary produces the query that finds the fix.
- Evaluate what comes back with four questions: is the source authoritative for this tool (its docs, its maintainers, its issue tracker, or someone whose other answers are right), is it current, does it match the version you have, and does it explain why rather than only what to type. A result that fails the fourth is a patch; the first three decide whether it is even a correct patch.
- Read the explanation until you could reproduce the fix without the page. That is the difference between the search having accelerated your understanding and having replaced it (Before You Copy Code).
The same problem, asked three ways
A query is a question, and question quality applies to it exactly as it does to a question asked of a person. The ladder below is the dashboard bug asked three times; the difference between rungs is not length or politeness but how much of the cause the query already contains.
The best form is not always reachable on the first attempt. When it is not, the second rung is the one to search — it finds the vocabulary that makes the third rung possible.
why The best form names the mechanism in the tool's own vocabulary, so a correct answer must contain those words and an incorrect one is unlikely to. It also makes the answer checkable: the docs page on effects and closures either confirms the mechanism or it does not. The vague form could be answered by anything; the middle form finds the right neighbourhood but cannot distinguish a closure bug from a dependency-array bug from a setter never being called.
Deciding what to believe
A result is not an answer until it has passed four checks, and the checks are cheap: who wrote it, when, for which version, and whether it explains the mechanism. The matrix is those four for the kinds of source a search usually returns. No row is "always trust" or "never trust"; each is where that source is strong and where it is not.
The last column is the one that decides whether the search accelerated understanding or replaced it.
| Source | Authoritative for | Currency and version | Explains why? |
|---|---|---|---|
| The tool's documentation | Intent: what the tool is designed to do | Usually current for the latest version; check the version switcher for yours | Often, in concept pages; reference entries state what, not why |
| The tool's issue tracker | Actual behaviour, including bugs and version-specific regressions | Dated and versioned by nature; read the thread to the end | Frequently — maintainers explain the cause when closing |
| A maintainer's post | Mechanism and design rationale | Check the date; rationale ages well, code samples do not | Almost always |
| A well-answered forum thread | A fix that worked for someone | Often stale; the accepted answer may predate your major version | Sometimes; the best answers explain, the accepted one may only patch |
| A tutorial or blog | One path that worked once | Rarely versioned; assume stale until shown otherwise | Varies; a code block with no explanation is a patch |
| An AI assistant | Nothing by itself; a synthesis to verify | Unknown; may blend versions without saying so | Will explain if asked — and the explanation must be checked against the docs (AI as Debugging Partner) |
What the fix looks like once it is understood
The dashboard fix is one line, and the line is not the point. The point is the sentence in the comment: if that sentence can be written without the search result open, the search did its job. If the line is pasted and the comment cannot be written, the same bug will be searched for again in the next component that polls.
The second version is the store's, with the mechanism stated in the store's terms.
1// Before: the interval's callback closed over `count` when the effect ran,2// so every tick reads the initial value and sets count = initial + 1 forever.3useEffect(() => {4 const id = setInterval(() => setCount(count + 1), 5000)5 return () => clearInterval(id)6}, [])7 8// After: the functional form receives the current value, so the closure does9// not matter. (The real dashboard fetches; the same shape applies to fetch-then-set.)10useEffect(() => {11 const id = setInterval(() => setCount((c) => c + 1), 5000)12 return () => clearInterval(id)13}, [])14 15// The test of the search: can you say, without the page open, why the16// first version's callback never sees a new count? If yes, the search17// accelerated understanding. If no, it replaced it.The fix is small enough that pasting it is tempting. The comment is the part that transfers to the next stale-closure bug, which will not look like this one.
How to do it
Most important first.
- Before typing, write one sentence naming the mechanism you suspect. If the sentence has only symptom words — "not updating", "broken" — you are not ready to search for the fix; search for the concept (Reading the Error Message).
- Put the exact error text in quotes when there is one, minus anything specific to you — paths, ids, variable names. An error message is the most searchable thing you own.
- Include the tool and, if it matters, the major version. "react 18" and "react 16" have different answers to some questions, and the query should say which you need.
- Prefer results from the tool's own documentation or issue tracker; then from a maintainer; then from an answer that explains the mechanism. Skip results that only show a code block (Evaluating What the Search Returned).
- Check the date and the version on the result, not only its content. A correct answer for a previous major version is a wrong answer with a convincing explanation.
- After applying a fix, write the mechanism in one sentence in your own words. If you cannot, the search found a patch and you still owe yourself the concept (The Feynman Check).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The order count. Symptom query: "react counter not updating" — hundreds of results about forgetting to call the setter. Mechanism, after a few minutes of thinking: the effect runs once, the interval it creates calls a function that closed over the count at that moment, so every tick sees the initial count. Mechanism query: "react useEffect setInterval stale closure" — the first result is a maintainer's explanation, the second is the docs page on effect dependencies, and both explain the functional update form of the setter. The fix is one line, and the explanation means the next stale-closure bug in the store will be recognised, not searched.
- An error with text: the checkout returns "unique constraint violation on orders_idempotency_key". Query, quoted, minus the table name: "unique constraint violation" "idempotency key". The database docs explain the constraint; the search adds nothing the docs did not, and the actual question — why is the key being reused — is a store question that no search will answer. The skill includes recognising when the search is done and the debugging begins (Debugging Is Problem Solving).
- A concept search: "how does React decide when an effect re-runs" — no symptom, no fix, just the mechanism. The docs page that answers it also explains three other bugs the store has not had yet.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Your query contains at least one term of art you did not have before you thought about the mechanism.
- The first page of results contains the tool's documentation or a maintainer, and you opened that one first.
- You can say the fix's mechanism in one sentence without the page open.
- You have discarded at least one plausible-looking result for being the wrong version or for explaining nothing.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What mechanism do I suspect, and can I name it in the tool's own vocabulary?
- ?Is there an exact error string I can search before I think any harder?
- ?Who wrote this result, when, and for which version — and does it say why?
- ?Could I reproduce this fix without the page open, and explain what was wrong?
- ?Has the search told me what I needed, so that the rest is debugging my own system?
What can go wrong
- Over-thinking before searching: a quarter of an hour spent naming a mechanism that the error message, pasted verbatim, would have found in a second. When there is an exact error string, search it first; the mechanism step is for symptoms without strings.
- Trusting authority alone: the tool's own docs are authoritative for the tool's intent and can still be wrong for your version, or silent on the interaction you have hit. Authority is one of four checks.
- Searching the mechanism and never applying it: the concept is understood, the fix is obvious, and an hour later the reader is three links deep in a related topic. The search had a goal; the goal was the count updating.
- Refusing to search at all as a point of pride. The search accelerates; the failure is only in letting it replace the understanding. Ten minutes of searching that yields a mechanism you now own is a good ten minutes.
- Naming the mechanism first costs minutes of thought before any result appears, and on a trivial problem the symptom query would have done.
- Preferring authoritative sources means sometimes reading a terse documentation page where a forum answer would have been clearer — the forum answer may be right, and you have to check it against the docs anyway.
- Evaluating every result on four axes is slower than opening the first one; on a low-stakes question the first one is often fine.
- "Better queries are longer queries." Better queries are more specific, which usually means shorter: the mechanism's terms of art, the tool, the version. Symptom words padding a query make it worse.
- "The docs are always right, so search the docs and stop." The docs are authoritative for intent. Whether the behaviour you see matches the intent is a question the docs cannot answer; the issue tracker and your own experiment can (Experiment Design).
- "If I understood the mechanism I would not need to search." Naming the mechanism is often half of understanding it; the search supplies the other half. The point is to arrive at the search with something, not to arrive without needing it.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe query as a statement of understood cause, and the four evaluation questions, apply to any tool and to any search medium — a search engine, an issue tracker, a chat log, an AI assistant. With an AI assistant the "is the source authoritative" question becomes "can I verify this against the docs", and the answer must be checked the same way.
- ILLUSTRATIVEThe dashboard count, the specific queries and the order of results are invented to show the shape of the skill; no search engine's actual ranking is being described, and the React mechanism is used because it is a well-known one.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Review the LLM's answer" at /manifesto/review applies the same four checks to an assistant's answer as this lesson applies to a search result: authoritative, current, your version, explains why.