The one idea
An error message is not a complaint. It is a report, written by someone trying to help you, in a compressed format.
Read it slowly, and pull out three things: what failed, where, and what it expected.
Not every message has all three. Getting even one of them moves you from "it's broken" to a specific question, which is the whole job.
Read the whole error, slowly. It usually says what went wrong and where.
Extract failure, location and expectation. Search the generic part of the message in quotes, with your own specifics removed.
An error names a violated expectation. The type tells you the class of fault, the location tells you where the assumption broke, and the message body tells you what value was received instead of what was required.
The three things
What failed
Usually the first few words, and often a named category. Permission denied.
File not found. #N/A. Invalid format. Connection timed out. 413 Payload Too Large.
The category alone often solves it. Permission denied means the thing exists
and you are not allowed — a different problem entirely from File not found,
which means it is not there. Treating both as "it didn't work" loses the
distinction that would have told you what to do.
Where
A filename, a line number, a cell reference, a field name, a step. Row 47.
Sheet2!B12. line 23. field: email.
Where is the most valuable part and the most ignored. If a message says row 47, go and look at row 47 first. Look at 46 and 48 too — those work, and comparing a failing case against a working one beats examining the failure alone.
What it expected
Often phrased as a contrast. Expected a number, got text. Required field.
Must be under 5 MB. Date must be in DD/MM/YYYY format.
This is the fix, stated directly. When a message tells you what it expected, you do not have a mystery — you have an instruction.
Errors you meet outside code
This is not only about software written by developers. The same reading applies everywhere.
| Where | Message | What it means |
|---|---|---|
| Excel | #N/A | The lookup ran and found nothing matching |
| Excel | #VALUE! | It got text where it needed a number |
| Excel | #REF! | A cell the formula pointed at was deleted |
| Excel | #DIV/0! | Dividing by an empty or zero cell |
| Web form | Please enter a valid email | Your entry failed a format check, often a stray space |
| Upload | File too large | It states a limit; your file exceeds it |
| Website | 404 Not Found | The address is wrong or the page moved |
| Website | 403 Forbidden | The page exists; you are not permitted |
| Website | 500 Internal Server Error | Their fault, not yours — retry later |
| Login | Account locked | Too many attempts; wait or reset, do not retry |
That last distinction is worth internalising: 404 and 403 look equally like failure and require opposite responses. A 500 means stop trying to fix your end.
How to search an error properly
Turning an error into a search that works
1 of 6Copy the message exactly. Do not retype from memory or paraphrase. If you cannot copy it, screenshot and transcribe carefully. One wrong word and you are searching for something that does not exist.
Excel shows: #VALUE! in a column of subtraction formulas. Half the column is
fine.
What failed: a value type mismatch. Where: the specific cells — go look at the ones that fail. What it expected: a number.
Compare a failing row with a working one. The failing rows have dates from a system export, left-aligned; the working rows are right-aligned. In Excel, left-aligned by default means text.
Diagnosis: those dates are text that looks like dates, and you cannot subtract text. You did not need to know that in advance — you needed to compare a failing case with a working one, which the "where" told you how to do.
A portal says: Upload failed. Please try again.
This message contains none of the three things, which is itself information — you are dealing with a system that will not tell you, so you must test instead.
Read the page around the box. Limits are usually printed near the upload field: maximum size, accepted formats, sometimes filename rules. Then test by likelihood: under the size limit? An accepted format — phone photos are often HEIC, which many portals reject? Spaces, brackets or non-English characters in the filename?
A useless error message does not mean you are stuck. It means the information is elsewhere on the page, and you supply the diagnosis the system declined to.
Try this
You see this in a browser console:
TypeError: Cannot read properties of null (reading 'value') at app.js:42
Without knowing any JavaScript, extract the three things.
Your challenge
Level 3 · IndependentCollect three real error messages this week — from anywhere: a spreadsheet, a website, a form, an app, a printer.
For each, write: what failed, where, what it expected, and the exact search string you would use with your own specifics stripped out.
Success criterion: each search string contains a quoted phrase, names the tool, and contains nothing unique to you. Then run one of them and see whether the first page of results is relevant. If it is not, adjust the length and try again — that adjustment is the skill.
What people usually get wrong
- Closing the box before reading it. The commonest error-handling behaviour there is, and the message is often gone for good.
- Reading only the first line. The useful location is frequently further down.
- Searching the whole message including your file paths. Guarantees zero results.
- Paraphrasing the error. "Excel not working with dates" finds nothing; the exact message finds the answer.
- Ignoring the "where". A message naming row 47 is doing most of your work.
- Assuming an error means you did something wrong. A
500is the server's fault;Account lockedis a security feature. Retrying either wastes time. - Trusting the first forum answer. Check the date and version — a 2018 fix may not apply, and may make things worse.
How someone experienced does it
Experienced people read long errors from the bottom up. The top says the most general thing; the bottom names the specific call or cell that broke. In a long stack of text, the last line mentioning something you wrote or configured is nearly always the relevant one — everything above is the tool's internals.
They also treat the first error as the only error. When six appear at once, five are usually consequences of the first. Fixing that one and re-running often clears all six, while working through them in order means solving five problems that do not exist.
The third habit: they notice what the error does not say. A message that says "connection failed" without naming a host, or "invalid input" without naming a field, tells you that the system does not know which part broke — and that means the fault is likely earlier than where the message appeared. Sparse errors point upstream.
When not to use this
Do not spend long decoding an error from a system you have no control over and no responsibility for. If a government portal throws an internal server error at 9pm, the diagnosis is "their end" and the fix is "try tomorrow morning". Reading it carefully takes ten seconds; researching it takes an evening you will not get back.
Do not search an error message that contains data belonging to your employer or a customer. Strip it first — see the note below.
Prove it
Add an error section to your stuck-log. Each entry: the exact message, what
it meant, the fix.
Within weeks you will recognise messages on sight, and the ones you recognise stop costing you anything. That recognition is what makes experienced people look fast — not knowing more errors, but having met these ones and written them down.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned explaining what an error message means and what commonly causes it. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood explaining what an error message means and what commonly causes it. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at reading and searching error messages — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.