Debugging & Problem Solving

Errors are expected — learn the mindset and tools to diagnose and fix problems systematically.

INFO

• Time: ~60 minutes
• Difficulty: Beginner-Intermediate
• What you'll learn: Reading errors, Chrome DevTools, debugging with AI

---

This Page Covers

• Mindset: errors are normal, not failures
• Reading and understanding error messages
• Using Chrome DevTools effectively
• Debugging with AI and knowing when to ask for help

---

Mindset: Errors Are Normal

Reframing Failure

Here is something that might surprise you: professional developers see errors every single day. Not occasionally. Every. Single. Day.

Errors are not a sign that you are doing something wrong. They are a normal part of building software. Think of them like typos when writing - you do not judge yourself for making a typo, you just fix it and move on.

When you see a red error message, your brain might want to panic. Instead, try thinking: "This is the computer telling me exactly what it needs." Errors are information, not judgment.

The Learning Opportunity

Every error you encounter teaches you something. The first time you see a particular error, it might take you an hour to figure out. The second time? Maybe 15 minutes. By the fifth time, you will recognize it instantly.

This pattern recognition builds naturally over time. Experienced developers are not smarter - they have just seen more errors and remember how they fixed them.

Patience and Persistence

Debugging often takes longer than writing the original code. This is normal. Professional developers sometimes spend entire days tracking down a single bug.

The key is to stay systematic rather than frustrated. Random changes rarely fix problems. A methodical approach - understanding what the error says, checking one thing at a time - will get you there faster than guessing.

---

Reading Error Messages

Anatomy of an Error

Error messages might look scary, but they follow a predictable pattern. Let us break down a typical error:

TypeError: Cannot read property 'map' of undefined
    at App.js:15:23
    at renderWithHooks (react-dom.js:1234)

This error has three important parts:

1. Error type (TypeError): This tells you the category of problem. A TypeError means you tried to do something with a value that does not support that operation.

2. Message (Cannot read property 'map' of undefined): This describes what went wrong. In this case, you tried to use .map() on something that does not exist.

3. Location (App.js:15:23): This tells you exactly where the error happened - file name, line number, and character position. Line 15, character 23 in App.js.

Stack Traces

The indented lines below the main error are called a "stack trace." They show the path the code took to reach the error:

TypeError: Cannot read property 'map' of undefined
    at App.js:15:23              ← Your code (the actual problem)
    at renderWithHooks (react-dom.js:1234)    ← Library code
    at mountIndeterminateComponent (react-dom.js:5678)
    at beginWork (react-dom.js:6789)

The stack trace reads top to bottom, from where the error happened down to what called it. The top line is usually the most important - that is where your code encountered the problem.

Finding the Relevant Line

When reading a stack trace, look for files from your project (like App.js or index.js), not library files (like react-dom.js). Your code is where you can make changes.

The pattern is simple:

1. Find the first line that mentions one of your files
2. Note the line number
3. Open that file and go to that line
4. Look at what is happening there

In our example, App.js:15:23 tells us to look at line 15 of App.js. That is where we are trying to use .map() on something that is undefined.

---

Chrome DevTools

Chrome has built-in tools for debugging websites. These are called DevTools, and they are your best friend when something goes wrong.

Opening DevTools

There are several ways to open DevTools:

• Keyboard shortcut: Press F12 or Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac)
• Right-click method: Right-click anywhere on the page and select "Inspect"
• Menu: Click the three dots in Chrome, go to More Tools, then Developer Tools

A panel will appear, usually at the bottom or right side of your browser.

Console Tab

The Console tab is where you will spend most of your debugging time. It shows:

JavaScript errors appear in red. These are problems that stopped your code from running correctly.

Warnings appear in yellow. These are not breaking anything right now but might cause problems later.

Log messages from your code appear when you use console.log(). This is how you can check what your code is doing:

// Add this to your code to see what a variable contains
console.log("User data:", userData);

You can also type JavaScript directly into the console to test things. Try typing 2 + 2 and pressing Enter - it will show 4.

Network Tab

The Network tab shows all the requests your page makes - loading images, fetching data from APIs, loading scripts.

This is especially useful when your app is not loading data correctly. Each row is a request:

• Status 200 means success (the request worked)
• Status 404 means not found (the URL does not exist)
• Status 500 means server error (something broke on the server)
• Status in red means the request failed completely

Click on any request to see details: what was sent, what came back, and any error messages.

Elements Tab

The Elements tab shows the HTML structure of the page and lets you inspect styles.

HTML inspection: You can see exactly what HTML is on the page. Click the arrow icon in the top-left of DevTools, then click any element on the page to see its code.

CSS inspection: The right panel shows all the styles applied to the selected element. You can see which styles are being applied and where they come from.

Live editing: You can actually change the HTML and CSS right in DevTools to test ideas. These changes are temporary - they disappear when you refresh the page. This is great for experimenting before making real code changes.

---

Debugging with AI

AI assistants like ChatGPT can be incredibly helpful for debugging. The key is giving them enough information to actually help.

Sharing Error Messages

When you encounter an error, copy the full error message, not just part of it. Include:

1. The complete error text - even the parts that look like gibberish
2. The stack trace - those indented lines showing the path to the error
3. Any relevant code - especially the file and lines mentioned in the error

Here is a good template:

I'm getting this error:

[paste full error message here]

Here's the code that's causing it:

[paste the relevant code]

I was trying to [explain what you were doing].

Describing the Problem

Context matters. Tell the AI:

What you expected to happen: "When I click the Submit button, the form should save and show a success message."

What actually happened: "Nothing happens when I click Submit. The button seems to work (it changes color when clicked) but no data saves."

Steps that led to the problem: "I added a new field to the form. It was working before I added the email field."

The more specific you are, the better help you will get.

Iterating on Solutions

Debugging with AI is a conversation, not a single question. The process looks like this:

1. Share the error and context
2. Try the AI's suggestion
3. Report what happened - Did it work? Did you get a new error?
4. Repeat until solved

If the first suggestion does not work, do not give up. Say something like: "I tried that, but now I'm getting this error instead..." and share the new error. Often the first attempt reveals more information that leads to the real solution.

---

How to Google Errors

Even with AI, sometimes a quick Google search is the fastest path to an answer. Here is how to search effectively.

Effective Search Queries

Put the error message in quotes to search for that exact phrase:

"Cannot read property 'map' of undefined"

Remove project-specific parts. If your error mentions myCustomFunction or UserComponent, remove those - other people will not have those same names:

Bad:  "Cannot read property 'map' of undefined" UserComponent
Good: "Cannot read property 'map' of undefined" React

Add the technology name. Include "React" or "Next.js" or "JavaScript" to filter results to your tech stack:

"Cannot read property 'map' of undefined" React hooks

Reading Stack Overflow

Stack Overflow is a question-and-answer site for developers. When you land on a page:

Check the date and votes. A highly upvoted answer from 2023 is probably better than a low-voted answer from 2015. Technology changes fast.

Read the comments. Sometimes the most helpful information is in the discussion below the answer, where people point out edge cases or better approaches.

Look for green checkmarks. The answer marked with a green checkmark was accepted by the person who asked the question - but that does not always mean it is the best answer. Check the vote counts too.

Evaluating Solutions

Before copying any solution into your code:

Does it make sense? If you do not understand what the code does, be cautious. Blindly copying code can introduce bugs or security problems.

Check for security issues. Be wary of solutions that:

• Ask you to disable security features
• Include API keys or passwords
• Suggest running code from user input without checking it first

Test it first. Try the solution in an isolated way if possible. Make sure you can undo the changes if it makes things worse.

---

When to Ask for Help

Knowing when to ask for help is a skill. Ask too early and you miss learning opportunities. Wait too long and you waste time spinning your wheels.

What to Try First

Before asking someone else, spend 15-30 minutes trying these steps:

1. Read the error carefully. What is it actually telling you?
2. Search for it. Put the error in Google or ask AI. Someone has probably seen this before.
3. Simplify the problem. Can you remove code until the error goes away? That helps identify what is causing it.
4. Check recent changes. What did you change right before this started happening?

If you have genuinely tried these steps and are still stuck, it is time to ask for help.

How to Ask Good Questions

The better your question, the faster you get a useful answer. Include:

A minimal example. Strip away everything except what is needed to show the problem. "Here's my entire 500-line file" is less helpful than "here's the 10 lines that are causing the issue."

What you have already tried. This prevents people from suggesting things you have already done. "I tried restarting the server and clearing the cache, but the error persists."

Be specific. "It does not work" is vague. "When I click Submit, nothing happens and I see this error in the console" is specific.

Where to Get Help

AI assistants (ChatGPT, Claude): Great for quick questions and debugging. Available instantly, patient with beginners, and can look at your code without judgment.

Stack Overflow: Good for specific, well-defined questions. Search first - your question has probably already been answered. If you post a question, follow their guidelines for good questions.

Discord and community channels: Many technologies have Discord servers or forums. Good for discussion-style help and connecting with other learners. Search the channel first before asking - someone might have asked the same thing recently.

---

Common Beginner Issues

Here are the errors you are most likely to encounter as a beginner, and how to solve them.

CORS Errors

CORS stands for Cross-Origin Resource Sharing. It is a security feature built into browsers.

Why browsers block this: Imagine if any website you visited could read data from your bank's website while you're logged in. A malicious site could steal your account balance, transaction history, or worse. CORS prevents this by making websites ask permission before accessing data from other domains.

What it means: Your website (running on one address like localhost:3000) is trying to fetch data from a different address (like api.example.com). The server at that address hasn't explicitly said "I allow requests from localhost:3000," so the browser blocks it to protect you.

How to recognize it: The error will say something like "blocked by CORS policy" or "No 'Access-Control-Allow-Origin' header."

Common solutions:

• If you control the API: Add CORS headers to allow requests from your site. This tells browsers "yes, this origin is allowed to access my data."
• If you don't control the API: Use a proxy through your own server — your server fetches the data, then passes it to your frontend. Server-to-server requests don't have CORS restrictions.
• During development only: Some browser extensions can temporarily disable CORS. Never use these in production — they exist purely for testing.

"Module not found"

Module not found: Can't resolve 'axios'

What it means: Your code is trying to use a package that is not installed, or the file path is wrong.

How to fix it:

1. Did you install it? Run npm install to install all dependencies. If it is a new package, run npm install package-name.

2. Is the import path correct? Check for typos. ./components/Button is different from ./Components/button.

3. Is it in package.json? Open package.json and check if the package is listed under "dependencies" or "devDependencies".

Port Already in Use

Error: listen EADDRINUSE: address already in use :::3000

What it means: Another program is already using port 3000 (or whatever port your app wants to use).

How to fix it:

1. Find and close the other program. Maybe you have another terminal window running the same project?

2. Use a different port. Many frameworks let you specify a different port:

   npm run dev -- --port 3001

3. Kill the process using the port. On Mac/Linux:

   lsof -i :3000
   kill -9 <PID>

Permission Denied

Error: EACCES: permission denied

What it means: Your computer is not allowing you to read, write, or execute something.

Common causes and fixes:

• File permission issues: The file might be locked or owned by another user. Try closing any programs that might have the file open.

• npm permission issues: Sometimes npm needs different permissions. The fix depends on your system - ask AI for help with your specific error message.

• When to use sudo: On Mac/Linux, sudo runs a command with administrator privileges. Use it sparingly and only when you understand why it is needed. Running everything with sudo can cause more problems than it solves.

Blank Screen (No Errors Visible)

Your page loads but shows nothing - just white.

First: Check the browser console. Press F12 and look at the Console tab. There almost certainly ARE errors - they are just not visible on the page itself.

Common causes:

• JavaScript errors that stop rendering. If your code crashes before it can display anything, you get a blank screen. The console will show what went wrong.

• Build errors vs runtime errors. Sometimes the code builds successfully but crashes when it runs. Check the terminal where your dev server is running AND the browser console.

• Check the Network tab. Maybe your page is waiting for data that never arrives. Look for failed requests (shown in red).

"It Works on My Machine"

Your code works perfectly when you run it locally, but fails when deployed.

Common causes:

• Environment variables: Your local .env file has values that the deployment server does not have. Check that all required environment variables are set in your deployment platform.

• Different Node versions: Your computer might have Node 18, but the server is running Node 16. Check your deployment platform's settings.

• Case sensitivity: Mac and Windows ignore capitalization in file names. Linux (most servers) does not. Button.js and button.js are different files on Linux.

• Missing dependencies: Did you forget to add a new package to package.json? It works locally because you installed it manually, but deployment runs a fresh npm install.

---

Testing Before You Ship

Before deploying any project, run through a basic testing checklist. Finding issues locally is much easier than debugging in production.

Manual Testing Checklist

Before every deployment, check these basics:

Functionality:

• [ ] All links work (no 404 errors)
• [ ] Forms submit correctly and show success/error messages
• [ ] Buttons do what they are supposed to do
• [ ] Images load (no broken image icons)
• [ ] Data displays correctly (if your app fetches data)

Visual:

• [ ] Page looks correct on desktop (full width)
• [ ] Page looks correct on mobile (resize your browser to ~375px wide)
• [ ] Text is readable (no tiny fonts, no low contrast)
• [ ] Nothing overflows or gets cut off

Edge cases:

• [ ] Empty states work (what happens with no data?)
• [ ] Error states work (what if the API is down?)
• [ ] Loading states work (does something show while data loads?)

Cross-Browser Testing

Your site should work in different browsers. At minimum, test in:

1. Chrome - Most users
2. Safari - Mac and iPhone users
3. Firefox - Good for catching weird bugs

How to test: Open your deployed site (not localhost) in each browser. Click around, fill forms, resize the window. If something looks broken, note which browser and what happened.

Quick tip: Most issues appear in Safari. If it works in Chrome and Safari, it probably works everywhere.

Mobile Device Testing

Resizing your browser is a good start, but real phones behave differently.

Test on a real phone:

1. Deploy your site (localhost will not work on your phone)
2. Open the deployed URL on your phone
3. Test all the same things: links, forms, buttons, scrolling

Common mobile issues:

• Touch targets too small (buttons/links hard to tap)
• Horizontal scrolling (content wider than screen)
• Keyboard covers input fields
• Slow loading (phones often have slower connections)

Lighthouse Audit

Chrome has a built-in audit tool called Lighthouse:

1. Open your site in Chrome
2. Open DevTools (F12)
3. Click the "Lighthouse" tab
4. Click "Analyze page load"

Lighthouse scores your site on:

• Performance - How fast it loads
• Accessibility - How usable for people with disabilities
• Best Practices - Security and code quality
• SEO - Search engine visibility

What to aim for: Green scores (90+) are great. Yellow (50-89) is acceptable. Red (under 50) means something needs attention.

For simple static sites, hitting 90+ on all scores is achievable. For complex apps, focus on accessibility and performance first.

Do not obsess over perfect scores. A shipped project with 85s is better than an unshipped project waiting for 100s. Run the audit, fix the easy wins, and ship.

---

Key Takeaways

• Errors are expected and informative, not failures
• Read error messages carefully—they usually tell you what's wrong
• Chrome DevTools shows console errors, network requests, and HTML/CSS
• AI can help debug if you share full context and error messages
• Good questions include what happened, what you expected, and what you tried