From Copy-Pasting Error Messages to Actually Reading Them

DevGlish Team

For the first three years of my career, my debugging workflow looked like this: see red text in the terminal, select all of it, copy, paste into Google, click the first Stack Overflow result, apply the fix. If it worked, move on. If it didn't, try the second result.

I never actually read the error message.

This sounds ridiculous when I write it out, but it was a deeply ingrained habit. English was my second language. Error messages were dense, full of technical jargon, and often grammatically unusual ("cannot read properties of undefined" — undefined what? properties of what?). My brain had learned to treat them as opaque tokens rather than as sentences containing useful information.

The moment this changed was when I was pair-programming with a colleague and hit a TypeError: Cannot read properties of null (reading 'map'). I reached for Google. She said "Wait — read the error. It's telling you exactly what happened."

She broke it down: "Cannot read" — JavaScript tried to access something. "Properties of null" — the thing it tried to access was null, not an object. "Reading 'map'" — specifically, it tried to access the .map property. So: somewhere in your code, you're calling .map() on a value that is null instead of an array.

She found the bug in about thirty seconds. It would have taken me ten minutes of scrolling through Stack Overflow to reach the same conclusion.

Why error messages felt unreadable

Looking back, I can identify why I'd developed the copy-paste habit. Error messages use a specific subset of English that's unlike anything else you encounter:

They use passive voice extensively. "Cannot be assigned to parameter of type 'string'" is passive and compressed. In natural English, you might say "You can't assign this value because the parameter expects a string." Error messages drop the subject ("you"), drop the explanation ("because"), and compress everything into a noun phrase.

They reference abstract concepts by name. "Unresolved reference," "implicit coercion," "type mismatch," "segmentation fault" — each of these is a compressed description of a complex concept. If you don't know what "coercion" means in a programming context (it means automatic type conversion), the error message is gibberish.

They follow grammar patterns that are rare outside of technical writing. "Expected ';' but found '}'" uses a construction you almost never see in everyday English. The subject is omitted, two past participles are used without auxiliaries, and the meaning depends on understanding compiler terminology.

For a non-native speaker, each error message is a puzzle where you need to decode the grammar, understand the technical vocabulary, and then map the result onto your code — all while dealing with the frustration of a bug. No wonder I defaulted to Google.

Learning to read errors as sentences

After the pair-programming session, I decided to actually start reading error messages before searching for them. I developed a simple technique: I'd mentally rewrite the error as a full English sentence.

TypeError: 'NoneType' object has no attribute 'split'
Becomes: "You called .split() on something, but that something is None (null). Python expected an actual object with a .split() method, but it got None instead."

error[E0382]: borrow of moved value: 'data'
Becomes: "You tried to use the variable 'data', but Rust already moved ownership of that value somewhere else. You can't use it anymore after moving it."

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Becomes: "Node.js tried to allocate memory and failed because it ran out. Your program is using too much memory."

The act of translating these compressed error messages into full sentences forced me to understand each word. When I didn't understand a word — "borrow," "allocation," "coercion" — I'd look it up in context. DevGlish was useful here because it explains programming terms as programming terms, not as everyday English words. "Borrow" in Rust doesn't mean the same thing as borrowing a book.

The compound effect on debugging speed

Within a few months, something shifted. I started reading error messages automatically, without the conscious effort of mental translation. My debugging speed roughly doubled — not because I became a better programmer, but because I stopped going through the intermediate step of searching, reading, and filtering Stack Overflow results.

Here's a concrete example. One afternoon, I hit this error in a TypeScript project:

Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'.

Before, I would have Googled this and read a two-paragraph Stack Overflow answer explaining optional types. Now, I read the error: the value might be undefined, but the target expects a definite string. I added a null check. Fixed in fifteen seconds.

Another example: error: cannot find module '@/utils/helpers'. Old me would Google "cannot find module typescript." New me reads the error: it can't find this specific module at this specific path. I check the path, notice a typo, fix it. Done.

These are small examples, but they add up. If you debug 5-10 errors a day and save even 2 minutes per error by reading it directly, that's 10-20 minutes daily. Over a year, that's significant.

Error messages as English teachers

An unexpected benefit: error messages turned out to be excellent English vocabulary teachers. They introduced me to precise, technical English in a context where understanding mattered immediately. When a compiler tells you about "implicit conversion," you learn that word right now because you need it right now.

Some vocabulary I learned almost entirely from error messages:

These are words that appear in documentation, tech talks, and code reviews. Learning them through error messages gave me vocabulary I used everywhere else.

Advice for developers who still copy-paste

If you recognize yourself in this article — if your reflex is to select, copy, paste, Google — I'd encourage you to try something different for one week. Before searching, spend thirty seconds reading the error message. Try to rewrite it as a plain English sentence. Identify the key noun (what's wrong) and the key verb (what was attempted).

You won't understand every error message immediately. Some are genuinely cryptic, even for native speakers. But you'll be surprised how many are actually quite clear once you slow down and parse them as sentences rather than as blocks of red text to be escaped from as quickly as possible.

The error message is the compiler talking to you. It's worth learning its language.

Related Articles