# Getting help

Reading an error, searching for yourself, and asking a question somebody can work with. The skill you keep using for the rest of your career.

Multimedia & Creative Technology · 0.0 General · Self-study · version 1.0.1 · 2026-09-30

Tags: general, debugging

Slides: <https://slides.mctantwerp.be/en/general/04-getting-help>

Speaker notes: <https://slides.mctantwerp.be/en/general/04-getting-help.notes.md>

<!-- slide 2 -->

## Agenda

1. Being stuck: What you do in the first five minutes
2. Error messages: Where the useful part sits
3. Searching: What you paste in the search bar
4. Debugging: Halving until you find it
5. The question: Five ingredients
6. Practice: Drills and your own bug

<!-- slide 3 -->

## Self-study: How to work through this

*30 minutes, On your own*

Count on half an hour. The drills sit in the middle of the deck, so work through it in one go.

1. Keep your last error message at hand, you need it at the end
2. The trace drill and the question lab are the real work
3. Finish with a rewritten question in #help-needed

<!-- slide 4 -->

## 1. Being stuck

*It is part of the job. The difference is how long you stay there.*

<!-- slide 5 -->

**Being stuck is the job.**

Everybody who writes code gets stuck every day. People with twenty years behind them too. They just have a routine to get out faster.

<!-- slide 6 -->

### The first five minutes

- Read the error. Actually read it, do not close it
- Look at what it points to: file, line, column
- Ask yourself what you changed last
- Put that back and see whether it works again
- Change one thing at a time, not five

> [!TIP]
> **Half of them end here**
>
> A typo, a wrong path, a forgotten import. The message usually says so.

<!-- slide 7 -->

### The twenty minute rule

*A timer on your search keeps you from losing an afternoon to a missing comma.*

1. **0 to 20 minutes**: You alone. Read, search, try. This is where you learn the most, so those twenty minutes never get skipped.
2. **After 20 minutes**: Write your question out. Writing it down often solves it, and otherwise your question is ready to go.
3. **After 40 minutes**: Send it. In the channel, to a classmate, to your lecturer. Sitting there longer gains you nothing.

> [!WARNING]
> Being stuck for three days and only saying so afterwards is not perseverance. It is three days gone.

<!-- slide 8 -->

### The rubber duck

*You explain your problem to something that knows nothing about code. Halfway through your own explanation you spot it.*

#### How it goes

- You say out loud what your code does, line by line
- To a rubber duck, a plant or your housemate
- At the line you cannot explain, you stop
- That is usually where it sits

#### Why it works

- Saying it out loud is slower than reading, so you skip nothing
- You have to put it in words, and that only works when you understand it
- You tell what the code should do, not what it says
- Which is why writing out a question works just as well

<!-- slide 9 -->

## 2. Error messages

*Not a punishment, just the only thing your machine can say about what went wrong.*

<!-- slide 10 -->

### What sits in a message

*Four parts, always the same four, in every language and every framework.*

```bash
TypeError: Cannot read properties of undefined (reading 'name')
    at Profile (src/components/Profile.jsx:12:18)
    at renderWithHooks (node_modules/react-dom/cjs/react-dom.development.js:16305:18)
    at mountIndeterminateComponent (node_modules/react-dom/cjs/react-dom.development.js:20074:13)
```

- **The type and the message**: `TypeError` says what kind of error, the sentence behind it says what went wrong.
- **File, line, column**: `Profile.jsx:12:18` is line 12, character 18. That is where you start looking.

<!-- slide 11 -->

### The first line that is yours

*A stack trace runs from the crash down into code you never wrote.*

- Anything with `node_modules` or `vendor` in it is not yours
- Read top down for the first line with `src/` or your own folder name
- That is the trigger, even if the mistake sits one step earlier
- The lines below it are the route your code took to get there

> [!NOTE]
> Frameworks push their own frames in between. As long as the path points at a package, that is their code calling yours.

<!-- slide 12 -->

### Trace drill

*Six messages the way they land on your screen. One line each holds the answer.*

<!-- slide 13 -->

### Messages you will meet

*Five classics, and what they actually mean.*

| The message | What is going on | Where you look |
| --- | --- | --- |
| `Cannot read properties of undefined` | You read something out of a variable that is not there | The line above: where does that variable come from |
| `is not a function` | The name exists, but it is not a function | A typo, or an import that returns something else |
| `ENOENT: no such file or directory` | The path is wrong | Capitals, one folder too high, or the file really is gone |
| `EADDRINUSE` | The port is taken | A second terminal with your server still running |
| `command not found` | The command is not in your PATH | Not installed, or reopen your terminal |

<!-- slide 14 -->

### Four more

*Three messages and a white screen, every semester again.*

| The message | What is going on | Where you look |
| --- | --- | --- |
| `Unexpected token <` | You expected JSON, the server sent HTML | The url is wrong, you got a 404 page back |
| `CORS policy` | The browser blocks the answer | The server has to send the header, your code cannot |
| `permission denied` | You are not allowed to write there | Wrong folder, or something that should not need sudo |
| A white screen with no message | The error is in the console, not on the page | Developer tools, Console tab |

<!-- slide 15 -->

### You see `Unexpected token < in JSON at position 0`. What happened?

- A. The server sent HTML instead of JSON
- B. Your JSON file is missing a comma
- C. You are on the wrong version of Node
- D. The API is offline

**Answer:** A. The server sent HTML instead of JSON

That less-than sign is the start of <!DOCTYPE html>. Your url pointed at a page instead of the API, or you got a 404 back. Check the Network tab to see what really came in.

<!-- slide 16 -->

## 3. Searching

*A search query is a skill too. Most answers are already out there.*

<!-- slide 17 -->

### What you paste in the search bar

*The error message, without everything that only exists on your machine.*

#### Not like this

```bash
TypeError: Cannot read properties
of undefined (reading 'temp') at Weather
(/Users/sam/Code/portfolio/src/
components/Weather.jsx:14:28)
```

Your path, your file name, your line number. Nobody else ever typed that, so you get zero results.

#### Like this

```bash
"Cannot read properties of undefined"
react fetch json
```

The message in quotes, plus the two or three words that describe your situation. Somebody asked this before.

<!-- slide 18 -->

### Search tricks

*Five things that turn 2 million results into the right answer.*

| What you type | What it does |
| --- | --- |
| `"this exact sentence"` | Searches the sentence literally instead of loose words |
| `site:stackoverflow.com` | Results from that site only |
| `react 19 useEffect` | Version number included, or you get answers from 2016 |
| `-w3schools` | Leaves a site out |
| `after:2024` | Recent pages only, handy with frameworks |

> [!NOTE]
> Search in English. Anything else gives you a fraction of the results, and rarely the good ones.

<!-- slide 19 -->

### Where you end up

*Not every source is equally reliable. This order works.*

- **[The official docs](https://developer.mozilla.org)**: MDN for anything that runs in the browser, and the site of the framework itself. Always current, usually with examples.
- **[Stack Overflow](https://stackoverflow.com)**: Check the date and the version in the question. An accepted answer from 2013 can be completely out of date.
- **[GitHub issues](https://github.com/search?type=issues)**: For bugs in a package. Search your message in the issues of the repo, there is often a workaround.
- **Blog posts and videos**: Good for understanding something, less for fixing something. Check the date before you copy anything.

<!-- slide 20 -->

### Code you find

*Copying is fine, as long as you can explain it afterwards.*

#### Do

- Read what it does before you paste it
- Rename the variables to your own names
- Test it with your data, not the example data
- Put the source in a comment above it

#### Do not

- Paste five answers in a row until something works
- Keep a solution you cannot explain
- Install an npm package because somebody said so
- Run `sudo` blindly because an answer told you to

<!-- slide 21 -->

## 4. Debugging

*Halving until there is nothing left to go wrong.*

<!-- slide 22 -->

### Just print it

*The simplest technique is still the fastest one.*

```js
// Not: "the data is wrong"
// But: looking at what is actually in there
console.log('response:', data)
console.log('type:', typeof data, 'length:', data?.length)

// In a loop: where does it go wrong
items.forEach((item, i) => console.log(i, item.id, item.price))
```

> [!TIP]
> Add a label. Ten times `console.log(x)` in your console is as useless as none at all.

<!-- slide 23 -->

### Binary search in your own code

*You do not know where the bug sits, so you halve until you do.*

1. **Switch off half**: Comment out half your code. Does it work now? Then the bug is in that half. Still broken? Then it is in the other one.
2. **Repeat**: Halve the suspect part again. After a handful of rounds you are down to two lines.
3. **Put it all back**: Remove your comments before you move on, or there is dead code sitting there next week.

> [!NOTE]
> Works without code too: switch off a css rule, remove a package, or check out an older commit that still worked.

<!-- slide 24 -->

### Six questions for yourself

- What did I change last?
- Does it work for somebody else? Then it is my environment
- Did I save and reload? Is the right server running?
- Is there a typo in a name I made up myself?
- Am I getting the data I think I am getting?
- Can I make it smaller and still break it?

> **The smallest example**
>
> Cut everything away until ten lines are left that still show the bug. You usually find it while cutting.

<!-- slide 25 -->

### What your browser already keeps for you

*The developer tools sit in every browser, behind F12 or right click and Inspect.*

| Tab | What for |
| --- | --- |
| Console | Error messages and your own logs |
| Network | Which requests went out, what came back, which status |
| Elements | The HTML as it is now, with the css that really applies |
| Application | localStorage, cookies, whatever your site stored |
| Sources | Breakpoints and stepping through your code |

<!-- slide 26 -->

## 5. The question

*Letting somebody help you starts with what you put in.*

<!-- slide 27 -->

**"It does not work" is not a question.**

A question without context costs three messages back and forth before anybody can start. With context you often get the answer straight away.

<!-- slide 28 -->

### Question lab

*The same bug, once as a cry for help and once as a question somebody can work with.*

<!-- slide 29 -->

### Two habits that help

*Both cost you nothing and save you half a day of waiting.*

#### No lonely hello

- A message with only `hey` leaves the other person waiting for the real question
- Put your question in that same message
- Whoever has time will answer. Whoever does not, reads it later

#### Do not ask to ask

- `Anyone good at css?` gets you no answer
- Just ask the question, then somebody knows whether they can help
- In the channel, not in a dm. The next person with the same bug finds it back

<!-- slide 30 -->

### The XY problem

*You ask about your solution instead of your problem, and get help down the wrong road.*

- **What you ask**: "How do I get the last three characters of a file name?"
- **What you want**: The extension. But `archive.tar.gz` has six and `Makefile` has none. Your question sends everybody down the wrong path.

> [!TIP]
> Always say what you are trying to achieve in the end. Then you can be halfway down the wrong approach and somebody will spot it.

<!-- slide 31 -->

### Sharing code

*How you send your code decides whether anybody can do something with it.*

#### Do this

- A code block with three backticks and the language behind them
- Only the part that matters, plus the lines around it
- A link to your repo or a branch when it is bigger
- The full error message as text

#### Not this

- A photo of your screen taken with your phone
- A screenshot of code somebody has to retype
- Four hundred lines in one message
- Only `see attachment` with no explanation

<!-- slide 32 -->

### Where you can go

*Four places, each with their own pace.*

| Where | When | What to expect |
| --- | --- | --- |
| The person next to you | Right away | A second pair of eyes, often enough |
| `#help-needed` | Within the hour | Somebody who recognises the problem |
| Your lecturer | During class or by appointment | Explanation of what you do not understand, not a debug service |
| Stack Overflow | Hours to days | A strict audience, so your question has to be finished |

> [!NOTE]
> Solved it? Say what it was. The next person who gets stuck finds your message.

<!-- slide 33 -->

## 6. Practice

*Your own last bug, and a question you dare to send.*

<!-- slide 34 -->

### You have been stuck on the same error for two hours. What do you do?

- A. Write your question out with the message, the code and what you tried
- B. Keep going for another hour, otherwise you learn nothing
- C. Start another part of the assignment
- D. Send your lecturer a dm

**Answer:** A. Write your question out with the message, the code and what you tried

Writing it out forces you to line everything up, which often solves it on the spot. If not, your question is ready for the channel, where more people read along than in a dm.

<!-- slide 35 -->

### Cheat sheet

*The order you work through it in.*

- **Read**: The type, the message, the file and the line. The first line that points at your code.
- **Look back**: What you changed last. Put it back, change one thing at a time.
- **Search**: The message without your own paths, in English, with your version added.
- **Halve**: Comment out half, print what is really in your variables.
- **Write it out**: What you want, what happens, what you tried, which versions.
- **Ask**: In the channel, with a code block and the full message. And say afterwards what it was.

<!-- slide 36 -->

### Task: Ask one real question

*15 minutes, On your own*

Take the last error you got stuck on. Even if you solved it since, write the question out anyway.

1. Describe in one sentence what you are trying to achieve
2. Paste the full error message as text, not a screenshot
3. Add the piece of code that causes it, in a code block
4. Say what you already tried and what your setup is
5. Post it in #help-needed, or keep it ready for next time

<!-- slide 37 -->

### Further

*Three pages you read once and keep forwarding after that.*

- **[nohello.net](https://nohello.net)**: Why a message with only "hello" costs everybody time.
- **[dontasktoask.com](https://dontasktoask.com)**: Why you are better off asking the question straight away.
- **[How to create a minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example)**: How to cut a problem down to the smallest example.
- **[How to ask a good question](https://stackoverflow.com/help/how-to-ask)**: The manual from Stack Overflow, strict but fair.

## Glossary

- **Twenty minute rule**: For twenty minutes you search on your own, then you write your question down. After forty minutes you ask it, because staying stuck longer gets you nothing. (slide 7)
- **Rubber duck**: You explain your code out loud, line by line, to something that knows nothing about code. The line you cannot explain is usually where the bug sits. (slide 8)
- **Error message**: The type of error (TypeError) with a sentence on what went wrong, and the file with line and column. Profile.jsx:12:18 is line 12, character 18: that is where you start looking. (slide 10)
- **Stack trace**: The lines under an error message, from the crash down into code you never wrote. Skip anything with node_modules or vendor and look for the first line that points at your own code. (slide 11)
- **Cannot read properties of undefined**: You read something out of a variable that is not there. Look at where that variable comes from, usually a line higher up. (slide 13)
- **is not a function**: The name exists, but it is not a function. Usually a typo, or an import that returns something else. (slide 13)
- **ENOENT**: No such file or directory: the path is wrong. Check the capitals and whether you are one folder too high, or the file really is gone. (slide 13)
- **EADDRINUSE**: The port is already taken, usually by a second terminal where your server is still running. (slide 13)
- **Unexpected token <**: You expected JSON and got HTML: that < is the start of <!DOCTYPE html>. Usually the url is wrong and you got a 404 page back. (slide 14)
- **CORS**: A browser rule that blocks the answer from another server. That server has to send the Access-Control-Allow-Origin header, your code cannot fix it. (slide 14)
- **console.log**: Prints what is actually inside a variable to the console. Add a label, like console.log('response:', data), or you will not know which line shows what. (slide 22)
- **Binary search**: Comment out half your code and check whether the bug stays. You keep halving the suspect part until two lines are left, and then you put everything back. (slide 23)
- **Minimal reproducible example**: The smallest example that still shows the bug: you cut everything away until about ten lines are left. You usually find the bug while cutting. (slide 24)
- **Developer tools**: The tools in every browser, behind F12 or right click and Inspect. Console holds your error messages, Network shows which requests went out and what came back. (slide 25)
- **XY problem**: You ask for help with your own solution instead of your problem, and everybody helps you further down the wrong road. So always say what you are trying to achieve in the end. (slide 30)
- **No hello**: Never send a message with only "hey" and then wait. Put your question in that same message, so whoever has time can answer straight away. (slide 29)
- **Don't ask to ask**: Do not ask whether anyone is good at css, just ask your question. Then whoever reads it knows right away whether they can help. (slide 29)
- **#help-needed**: The Discord channel for when you are stuck, usually with an answer within the hour. Post there instead of in a dm, and say what it was once it is solved. (slide 32)

## Links and sources

### In the deck

- [The official docs](https://developer.mozilla.org) (slide 19)
- [Stack Overflow](https://stackoverflow.com) (slide 19)
- [GitHub issues](https://github.com/search?type=issues) (slide 19)
- [nohello.net](https://nohello.net) (slide 37)
- [dontasktoask.com](https://dontasktoask.com) (slide 37)
- [How to create a minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) (slide 37)
- [How to ask a good question](https://stackoverflow.com/help/how-to-ask) (slide 37)