How Developers
Actually Think

Every programming course teaches you syntax. HTML, CSS, JavaScript, Python — the words and grammar of code. But there is something they almost never teach you: what to do when the code breaks. And it will always break. Not occasionally. Constantly. Even after 10 years at Google.

Here is the number that should permanently change how you think about learning: professional developers spend roughly 50–70% of their time not writing new code — but reading code, understanding systems, tracking down bugs, and figuring out why something behaves unexpectedly. Writing is the smaller half of the job.

This essay gives you the mental toolkit that experienced developers build unconsciously over years of frustrating mistakes. You are getting it now, before you write a single line of real code, so that every bug you encounter from Essay 1.1 onwards becomes a learning experience rather than a reason to quit.

By the end of this essay, you will have: a 5-step debugging process you can use for any error; a method for Googling that finds answers in under 3 minutes; the ability to read any error message without fear; and the discipline to struggle productively rather than give up too early or too late.

You have set up your development environment (0.1) and learned to navigate the terminal (0.2). Now before you write a single HTML tag or line of JavaScript, we install the operating system for your brain. This is the last thing you do before the real code begins.

Every single essay from 1.1 onwards will involve moments where something does not work as expected. You will get red error messages. Things will appear blank when they should not. Code will run but do the wrong thing. Each of those moments is where this essay activates. The techniques here are not specific to HTML or JavaScript — they apply to every language and framework you will ever learn.

The Doctor Who Does Not Know Everything

A doctor does not memorise every disease. There are over 10,000 recognised diseases — no human brain holds all of them. What doctors learn instead is a diagnostic process: gather symptoms, form a differential diagnosis, run targeted tests, narrow down, treat.

A developer cannot memorise every possible bug or error. There are infinite ways for code to go wrong. What you learn instead is the same: a diagnostic process. Observe the symptoms (the error message), form a hypothesis (what I think is causing it), run a targeted test (change one thing and see what happens), narrow down, fix.

The IKEA Analogy: Reading the Manual First

Imagine building IKEA furniture without reading the instruction manual. You pick up pieces at random, try to fit them together, get frustrated, and eventually force something that almost works but wobbles. Now imagine reading the manual first — 20 minutes of reading saves 2 hours of frustration.

Documentation is your instruction manual. Error messages are your fault indicator light. Most beginners ignore both. Professionals read both — every time, without exception.

Below is the complete debugging process as a step-by-step walkthrough. Click each step to reveal what it means and how to actually execute it. Work through them in order the next time you hit a bug.

Part A — Anatomy of an Error Message

Error messages are not insults. They are the most precise, honest communication your computer will ever give you. Learning to read them fluently is one of the highest-leverage skills you will develop as a developer.

Every error message has the same anatomy:

• Error type — the category of error (ReferenceError, TypeError, SyntaxError, etc.). This alone tells you a huge amount about where to look.
• Error message — a human-readable description of exactly what went wrong. Read every word. Do not skim.
• File and line number — the exact location in your code. Go there immediately. The error is usually within 3 lines of this location.
• Stack trace — a list of function calls that led to the error, from bottom (where it started) to top (where it crashed). The bottom of the stack is almost always more useful than the top.

Part B — The Six Common Error Types in JavaScript

JavaScript, which you will learn in Phase 1, has six error types you will encounter constantly. Knowing what each type means saves you enormous time:

• SyntaxError — your code is grammatically incorrect. A missing bracket, a misspelled keyword, a comma in the wrong place. The code never even ran — it could not be parsed. Fix: look at the line number and check every bracket, quote, and punctuation mark.
• ReferenceError — you used a variable name that does not exist (never declared, or declared after you tried to use it). Fix: check spelling, check if you forgot to declare it with let or const, check the scope.
• TypeError — you tried to do something with a value that is the wrong type. Calling a function on something that is not a function. Accessing a property on undefined. Fix: add a console.log just before the error to inspect what the variable actually contains.
• RangeError — a number or value is outside the allowed range. Infinite recursion (a function calling itself forever) is the most common cause. Fix: look for a function that calls itself without a proper base case to stop it.
• URIError — you used a URI function (encodeURI, etc.) incorrectly. Rare for beginners.
• EvalError — related to the eval() function. You will almost never encounter this.

Part C — How to Google Like a Developer

There is a right way and a wrong way to search for solutions. The wrong way is copying the entire error message, including your specific variable names and file paths, into Google. The right way removes everything specific to your project and searches for the universal pattern.

After searching, always check: is the answer recent? (Check the date — technology moves fast. A Stack Overflow answer from 2014 may be dangerously outdated for a 2025 library.) Is it the accepted answer or the most upvoted answer? (Sometimes the most upvoted answer is better than the accepted one — read both.) Do you understand it before copying it? (If you cannot explain it, do not use it.)

Part D — How to Read Documentation

Documentation — the official manual for a language, library, or framework — is the most reliable source of truth available to you. Most beginners are intimidated by docs. Most experienced developers go directly to docs before anywhere else.

The key insight is that you do not read documentation like a novel. You do not start at page one and read to the end. You use it as a reference. Here is the professional process:

1. Use Ctrl+F (find) to search for the specific thing you need.
2. Scroll to the examples section first. Code examples are worth a thousand words of explanation.
3. After looking at an example, read the explanation above it.
4. Look at the parameters/options section to understand everything the function accepts.
5. Check the "Returns" section — know what comes back.

The best documentation sites for this series: developer.mozilla.org (MDN) for HTML/CSS/JavaScript, react.dev for React, expressjs.com for Express, postgresql.org/docs for PostgreSQL.

Part E — Rubber Duck Debugging

This sounds absurd. It works consistently.

Explain your code and your problem out loud to an inanimate object — a rubber duck, a mug, your phone. Walk through exactly what you expect the code to do, line by line. The act of forming sentences and explaining your logic forces your brain to engage differently than when you simply stare at code. In most cases, you will find the bug before you finish the explanation. The reason this works: when you write code, your brain fills in gaps with what you intended. When you explain it out loud, you are forced to say what the code actually does — and that gap between intention and reality is exactly where bugs live.

Part F — The 30-Minute Rule and Why It Matters

There is a tension beginners struggle with: how long should I struggle before getting help? Too short, and you never learn to think independently. Too long, and you lose hours on a problem a one-sentence answer would have solved.

The answer used consistently across professional development culture is 30 minutes. Spend at least 30 minutes of genuine, focused effort on a problem before reaching for external help. Not 30 minutes of staring blankly. 30 minutes of the 5-step process above: reading the error, isolating, hypothesising, testing.

After 30 minutes, if you are still stuck, asking for help is not just acceptable — it is the correct decision. But how you ask matters enormously. A good question includes: what you are trying to do, what you expected to happen, what actually happened (with the exact error message), and what you have already tried. Writing this out takes 5 minutes and solves about 40% of problems before you even send the message.

Below are five real JavaScript error messages you will encounter in Phase 1 and beyond. For each one, you will see the exact error, what it means, why it happened, and how to fix it. Study these now so they do not surprise you later.

const user = fetchUser(123);
console.log(user.name); // 💥 TypeError here

function showProfile() {
  console.log(userData.email); // 💥 ReferenceError
}

const userData = { email: 'rahul@example.com' };
showProfile();

function greet(name) {
  if (name) {
    console.log(`Hello ${name}`)
                      // Missing closing } for if block
}                     // 💥 JS thinks this closes the function

const response = await fetch('/api/users');
const data = await response.json(); // 💥 Error here

// The server returned HTML, not JSON
// response.json() tried to parse <!DOCTYPE html> as JSON

// ❌ Bad — tells you nothing useful in a huge log stream
console.log("here");
console.log(data);

// ✅ Good — labels the output, easy to locate
console.log("[fetchUser] response received:", data);
console.log("[submitForm] user object before validation:", user);

// ✅ Even Better — use console.table for arrays
console.table(users); // Shows array of objects as a clear table layout

// ✅ Timing your execution blocks
console.time('fetchUsers');
await fetchUsers();
console.timeEnd('fetchUsers'); // Outputs: fetchUsers: 234ms

These are the six exact mistakes that cause most beginners to waste hours on problems that should take minutes. Every experienced developer has made all of them. Reading this now means you make them fewer times.

The debugging process you are learning is not just for personal projects. At Google, Facebook, and Amazon, production systems crash in ways that affect millions of users. The companies have formalised these exact same habits into institutional processes. Understanding them now makes you sound genuinely senior in interviews.

The Incident Response Playbook

When a major system fails at a FAANG company, a standardised process activates. Knowing this process shows interviewers you think at scale:

1. Detect — automated monitoring alerts the team. Nobody finds out from a tweet.
2. Acknowledge — someone owns the incident immediately. No ambiguity about who is debugging.
3. Mitigate first — stop the bleeding before finding the root cause. Rollback the last deployment. Spin up extra servers. Restore service first, investigate second.
4. Diagnose — with service restored, find the root cause. Not the symptom — the cause. "The server ran out of memory" is a symptom. "A memory leak in the new image processing function" is the cause.
5. Fix and deploy — the actual code change.
6. Post-mortem — write it up. Share it. Make the organisation smarter.

FAANG technical interviews test your problem-solving process as much as your solution. An interviewer watching you think through a hard problem is evaluating something specific: does this person have a systematic process, or do they just hope for inspiration?

Answer each question out loud before flipping the card. Say your answer to the wall. Say it to your phone. This is not optional — speaking forces clarity in a way that reading alone never does. Click to reveal the answer after you have spoken yours.

These three tasks must be completed before you move to Essay 1.1. They take approximately 90 minutes total. Click each task to mark it done.

Before you are allowed to open Essay 1.1, you must be able to say these three things without hesitation. They are the non-negotiable takeaways from this essay.

Terms to Know