Narrowing — the smallest thing that still breaks

The method in the last lesson assumes you know roughly where to look. Often you do not. Something in forty lines is wrong and every line looks reasonable.

Narrowing is how you go from "somewhere in here" to "this line" without reading forty lines forty times.

Halve it

Disable half the program. Does it still break?

If yes, the problem is in the half that still runs. If no, it is in the half you disabled. Either way you just threw away half the search space with one run. Do it again. Forty lines becomes twenty, then ten, then three, in about five steps.

This works because it does not require you to understand the code. It only requires you to run it.

Build the smallest thing that still breaks

Now go the other way. Start a new empty file and add back the minimum needed to reproduce the failure. Strip until removing one more thing makes it work.

What you are left with is two valuable things at once. It is the answer — the failure lives in the last piece you could not remove. And it is the best possible question, because "these six lines produce this error and I expected this" is something an assistant, a colleague, or a search engine can actually answer. "My app is broken" is not.

A worked example

Your request from the last unit stops returning prices. Three beliefs, three checks, in order:

const url = `https://eodhd.com/api/real-time/${symbol}?api_token=${token}&fmt=json`;
console.log("url:", url.replace(token, "***"));  // 1. is the address what I think it is?

const res = await fetch(url);
console.log("status:", res.status); // 2. did the server accept it?

const body = await res.text();
console.log("body:", body);         // 3. what actually came back?

Each print kills a whole class of possibility. A URL with undefined in it means the failure is upstream, where the symbol was set. A status of 401 means the key, not the code. A body that is HTML rather than JSON means you got an error page and the parse was never going to work.

Notice the third one uses .text() rather than .json(). Parsing throws away the evidence: if the body is not JSON, .json() fails with a message about position 0, which tells you nothing about what the body actually was. Look at the raw text first.

Narrow the data, not just the code

The most common wasted afternoon is reading correct code very carefully while the input is wrong. If the code looks right, stop reading it and print what is going in. Where does this value come from? Is it the shape I assumed?

Try it now

Take your request script and break it three ways, one at a time: a misspelled symbol, a wrong key, and a URL missing fmt=json. Before fixing each, predict which of the three prints will show the problem. Being wrong about that prediction is the useful part.