# Hulp vragen

Een foutmelding lezen, zelf zoeken, en een vraag stellen waar iemand iets mee kan. De vaardigheid die je de rest van je carrière blijft gebruiken.

Multimedia & Creatieve Technologie · 0.0 General · Zelfstudie · versie 1.0.1 · 2026-09-30

Tags: general, debugging

Slides: <https://slides.mctantwerp.be/nl/general/04-hulp-vragen>

Speaker notes: <https://slides.mctantwerp.be/nl/general/04-hulp-vragen.notes.md>

<!-- slide 2 -->

## Agenda

1. Vastzitten: Wat je doet in de eerste vijf minuten
2. Foutmeldingen: Waar staat wat je nodig hebt
3. Zelf zoeken: Wat je in de zoekbalk plakt
4. Zelf debuggen: Halveren tot je het vindt
5. De vraag: Zes ingrediënten
6. Oefenen: Drills en je eigen bug

<!-- slide 3 -->

## Zelfstudie: Werkwijze

*30 minuten, Alleen*

Reken op een halfuur. De drills staan verspreid door het deck, dus werk het in één keer door.

1. Hou je laatste foutmelding bij de hand, die gebruik je achteraan
2. De trace-drill en het vragenlabo zijn het echte werk
3. Sluit af met een herschreven vraag in #help-needed

<!-- slide 4 -->

## 1. Vastzitten

*Het hoort bij het werk. Het verschil zit in hoe lang je blijft hangen.*

<!-- slide 5 -->

**Vastzitten is het werk.**

Iedereen die code schrijft, zit elke dag vast. Wie er al twintig jaar in zit ook. Die heeft alleen een routine om er sneller uit te raken.

<!-- slide 6 -->

### De eerste vijf minuten

- Lees de foutmelding. Echt lezen, niet wegklikken
- Kijk waar hij naar wijst: bestand, regel, kolom
- Vraag je af wat je als laatste veranderd hebt
- Zet het terug en kijk of het dan wel werkt
- Verander één ding tegelijk, niet vijf

> [!TIP]
> **De helft is hier al opgelost**
>
> Een typfout, een verkeerd pad, een vergeten import. De melding zegt het meestal gewoon.

<!-- slide 7 -->

### De twintig-minutenregel

*Een timer op je zoektocht zetten voorkomt dat je een namiddag verliest aan een komma.*

1. **0 tot 20 minuten**: Jij alleen. Lezen, zoeken, proberen. Hier leer je het meest, dus die twintig minuten sla je nooit over.
2. **Na 20 minuten**: Schrijf je vraag uit. Bij het opschrijven los je het vaak zelf op, en anders staat je vraag klaar.
3. **Na 40 minuten**: Stel ze. In het kanaal, aan een medestudent, aan je lector. Langer blijven zitten levert niets meer op.

> [!WARNING]
> Drie dagen vastzitten en het dan pas zeggen is geen doorzettingsvermogen. Dat is drie dagen kwijt.

<!-- slide 8 -->

### Het badeendje

*Je legt je probleem uit aan iets dat niets van code kent. Halverwege je eigen uitleg zie je het staan.*

#### Hoe het gaat

- Je vertelt hardop wat je code regel per regel doet
- Tegen een badeend, een plant of je huisgenoot
- Bij de regel die je niet kan uitleggen, stop je
- Daar zit hij meestal

#### Waarom het werkt

- Hardop uitleggen is trager dan lezen, dus je slaat niets over
- Je moet het in woorden zetten, en dat lukt alleen als je het snapt
- Je vertelt wat de code hoort te doen, niet wat er staat
- Precies daarom werkt een vraag uitschrijven even goed

<!-- slide 9 -->

## 2. Foutmeldingen

*Geen straf, maar het enige dat je machine kan zeggen over wat er mis is.*

<!-- slide 10 -->

### Wat er in een melding staat

*Vier stukken, altijd dezelfde vier, in elke taal en elk 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)
```

- **Het type en de boodschap**: `TypeError` zegt welke soort fout, de zin erachter zegt wat er precies misliep.
- **Bestand, regel, kolom**: `Profile.jsx:12:18` is regel 12, teken 18. Daar begin je te kijken.

<!-- slide 11 -->

### De eerste regel die van jou is

*Een stack trace loopt van waar het knalde tot diep in code die je nooit geschreven hebt.*

- Alles met `node_modules` of `vendor` erin is niet van jou
- Zoek van boven naar beneden de eerste regel met `src/` of je eigen mapnaam
- Daar zit de aanleiding, ook al ligt de fout soms een stap eerder
- De regels eronder zijn de weg waarlangs je code daar terechtkwam

> [!NOTE]
> Frameworks zetten hun eigen frames er soms tussen. Zolang het pad naar een pakket wijst, is het hun code die jouw code aanriep.

<!-- slide 12 -->

### Trace-drill

*Zes meldingen zoals ze op je scherm verschijnen. Telkens één regel met het antwoord erin.*

<!-- slide 13 -->

### Meldingen die je gegarandeerd tegenkomt

*Vijf klassiekers, met wat ze echt betekenen.*

| De melding | Wat er aan de hand is | Waar je kijkt |
| --- | --- | --- |
| `Cannot read properties of undefined` | Je leest iets uit een variabele die er niet is | De regel erboven: waar komt die variabele vandaan |
| `is not a function` | De naam bestaat, maar is geen functie | Typfout, of een import die iets anders teruggeeft |
| `ENOENT: no such file or directory` | Het pad klopt niet | Hoofdletters, een map te hoog, of het bestand staat er echt niet |
| `EADDRINUSE` | De poort is bezet | Een tweede terminal waar je server nog draait |
| `command not found` | Het commando staat niet in je PATH | Niet geïnstalleerd, of je terminal opnieuw openen |

<!-- slide 14 -->

### Nog vier

*Drie meldingen en een wit scherm, elk semester opnieuw.*

| De melding | Wat er aan de hand is | Waar je kijkt |
| --- | --- | --- |
| `Unexpected token <` | Je verwachtte JSON, de server stuurde HTML | De url klopt niet, je kreeg een 404-pagina terug |
| `CORS policy` | De browser blokkeert het antwoord | De server moet de header sturen, jouw code kan dat niet |
| `permission denied` | Je mag daar niet schrijven | Verkeerde map, of iets dat geen sudo hoort nodig te hebben |
| Een wit scherm zonder melding | De fout staat in de console, niet op de pagina | Developer tools, tabblad Console |

<!-- slide 15 -->

### Je ziet `Unexpected token < in JSON at position 0`. Wat is er gebeurd?

- A. De server stuurde HTML in plaats van JSON
- B. Je JSON-bestand mist een komma
- C. Je hebt een verkeerde versie van Node
- D. De API is offline

**Antwoord:** A. De server stuurde HTML in plaats van JSON

Dat kleiner-dan-teken is het begin van <!DOCTYPE html>. Je url wees naar een pagina in plaats van naar de API, of je kreeg een 404 terug. Kijk in het tabblad Network wat er echt binnenkwam.

<!-- slide 16 -->

## 3. Zelf zoeken

*Een zoekopdracht is ook een vaardigheid. De meeste antwoorden staan er al.*

<!-- slide 17 -->

### Wat je in de zoekbalk plakt

*De foutmelding, zonder alles wat enkel op jouw machine bestaat.*

#### Zo niet

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

Jouw pad, jouw bestandsnaam, jouw regelnummer. Niemand anders heeft dat ooit getypt, dus je vindt nul resultaten.

#### Zo wel

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

De melding tussen aanhalingstekens, plus de twee of drie woorden die jouw situatie beschrijven. Dit heeft iemand al gevraagd.

<!-- slide 18 -->

### Zoektrucs

*Vijf dingen die het verschil maken tussen 2 miljoen resultaten en het juiste antwoord.*

| Wat je typt | Wat het doet |
| --- | --- |
| `"exact deze zin"` | Zoekt de zin letterlijk, in plaats van losse woorden |
| `site:stackoverflow.com` | Alleen resultaten van die site |
| `react 19 useEffect` | Versienummer erbij, anders krijg je antwoorden van 2016 |
| `-w3schools` | Sluit een site uit |
| `after:2024` | Alleen recente pagina's, handig bij frameworks |

> [!NOTE]
> Zoek in het Engels. Nederlandse zoektermen geven je een fractie van de resultaten, en zelden de goede.

<!-- slide 19 -->

### Waar je uitkomt

*Niet elke bron is even betrouwbaar. Deze volgorde werkt.*

- **[De officiële docs](https://developer.mozilla.org)**: MDN voor alles wat in de browser draait, en de site van het framework zelf. Altijd actueel, meestal met voorbeelden.
- **[Stack Overflow](https://stackoverflow.com)**: Kijk naar de datum en naar de versie in de vraag. Een geaccepteerd antwoord van 2013 kan volledig achterhaald zijn.
- **[GitHub issues](https://github.com/search?type=issues)**: Voor bugs in een pakket. Zoek je melding in de issues van de repo, vaak staat er een workaround in.
- **Blogposts en video's**: Handig om iets te begrijpen, minder om iets op te lossen. Check de datum voor je iets overneemt.

<!-- slide 20 -->

### Code die je vindt

*Overnemen mag, zolang je erna kan uitleggen wat er staat.*

#### Wel doen

- Lees wat het doet voor je het plakt
- Hernoem de variabelen naar jouw namen
- Test het met jouw data, niet met die van het voorbeeld
- Zet de bron in een comment erboven

#### Niet doen

- Vijf antwoorden na elkaar plakken tot iets werkt
- Een oplossing overnemen die je niet kan uitleggen
- Een npm-pakket installeren omdat iemand het zei
- Blind `sudo` draaien omdat het in een antwoord stond

<!-- slide 21 -->

## 4. Zelf debuggen

*Halveren tot er niets meer over is om fout te lopen.*

<!-- slide 22 -->

### Print het gewoon

*De eenvoudigste techniek werkt nog altijd het snelst.*

```js
// Niet: "de data klopt niet"
// Wel: kijken wat er echt in zit
console.log('respons:', data)
console.log('type:', typeof data, 'lengte:', data?.length)

// In een lus: waar loopt het mis
items.forEach((item, i) => console.log(i, item.id, item.price))
```

> [!TIP]
> Zet er een label bij. Tien keer `console.log(x)` in je console is even nutteloos als geen enkele.

<!-- slide 23 -->

### Binair zoeken in je eigen code

*Je weet niet waar de fout zit, dus halveer je tot je het wel weet.*

1. **Zet de helft uit**: Comment de helft van je code weg. Werkt het nu? Dan zit de fout in dat stuk. Werkt het niet? Dan in de andere helft.
2. **Herhaal**: Halveer het verdachte stuk opnieuw. Na een handvol keer hou je twee regels over.
3. **Zet alles terug**: Haal je comments weg voor je verder gaat. Anders staat er volgende week nog dode code.

> [!NOTE]
> Werkt ook zonder code: zet je css-regel uit, haal een pakket weg, of check uit naar een oudere commit die wel werkte.

<!-- slide 24 -->

### Zes vragen die je jezelf stelt

- Wat heb ik als laatste veranderd?
- Werkt het bij iemand anders? Dan ligt het aan mijn omgeving
- Heb ik opgeslagen en herladen? Draait de juiste server?
- Staat er een typfout in een naam die ik zelf verzon?
- Krijg ik de data die ik denk te krijgen?
- Kan ik het kleiner maken tot het nog altijd misloopt?

> **Het kleinste voorbeeld**
>
> Snijd alles weg tot er tien regels overblijven die de fout nog tonen. Meestal vind je hem tijdens het snijden.

<!-- slide 25 -->

### Wat je browser al voor je bijhoudt

*De developer tools staan in elke browser, met F12 of rechtermuisknop en Inspecteren.*

| Tabblad | Waarvoor |
| --- | --- |
| Console | Foutmeldingen en je eigen logs |
| Network | Welke requests vertrokken, wat er terugkwam, welke status |
| Elements | De HTML zoals ze nu is, met de css die er echt op zit |
| Application | localStorage, cookies, wat je site bewaarde |
| Sources | Breakpoints zetten en stap voor stap door je code |

<!-- slide 26 -->

## 5. De vraag

*Iemand anders laten helpen begint bij wat jij erin steekt.*

<!-- slide 27 -->

**"Het werkt niet" is geen vraag.**

Een vraag zonder context kost drie heen en weer berichten voor iemand kan beginnen. Met context krijg je vaak meteen het antwoord.

<!-- slide 28 -->

### Vragenlabo

*Dezelfde bug, één keer als kreet en één keer als vraag waar iemand meteen mee verder kan.*

<!-- slide 29 -->

### Twee gewoontes die helpen

*Allebei kosten ze je niets en ze schelen een halve dag wachten.*

#### Geen "hallo" alleen

- Een bericht met enkel `hey` laat de ander wachten op de echte vraag
- Zet je vraag meteen in hetzelfde bericht
- Wie tijd heeft, antwoordt. Wie niet, leest het later

#### Vraag niet of je mag vragen

- `Iemand die goed is in css?` levert geen antwoord op
- Stel gewoon je vraag, dan weet iemand of hij kan helpen
- Publiek in het kanaal, niet in een dm. De volgende met dezelfde bug vindt het terug

<!-- slide 30 -->

### Het XY-probleem

*Je vraagt naar je oplossing in plaats van naar je probleem, en krijgt hulp bij de verkeerde weg.*

- **Wat je vraagt**: "Hoe haal ik de laatste drie tekens uit een bestandsnaam?"
- **Wat je wil**: De extensie weten. Maar `archive.tar.gz` heeft er zes, en `Makefile` geen. Je vraag stuurt iedereen het verkeerde pad op.

> [!TIP]
> Zeg er altijd bij wat je uiteindelijk wil bereiken. Dan mag je halfweg de verkeerde aanpak zitten, iemand ziet het.

<!-- slide 31 -->

### Code delen

*Hoe je je code doorstuurt, bepaalt of iemand er iets mee kan.*

#### Doe dit

- Een codeblok met drie backticks en de taal erachter
- Alleen het stuk dat telt, plus de regels errond
- Een link naar je repo of een branch, als het groter is
- De volledige foutmelding als tekst

#### Niet dit

- Een foto van je scherm met je gsm
- Een screenshot van code die iemand moet overtypen
- Vierhonderd regels in één bericht
- Alleen `zie bijlage` zonder uitleg

<!-- slide 32 -->

### Bij wie je terechtkan

*Vier plekken, elk met hun eigen tempo.*

| Waar | Wanneer | Wat je mag verwachten |
| --- | --- | --- |
| Je buur in het lokaal | Meteen | Een tweede paar ogen, vaak genoeg |
| `#help-needed` | Binnen het uur | Iemand die het probleem herkent |
| De lector | Tijdens de les of op afspraak | Uitleg bij wat je niet begrijpt, geen debugservice |
| Stack Overflow | Uren tot dagen | Streng publiek, dus je vraag moet af zijn |

> [!NOTE]
> Opgelost? Zet erbij wat het was. De volgende die vastloopt, vindt jouw bericht terug.

<!-- slide 33 -->

## 6. Oefenen

*Je eigen laatste bug, en een vraag die je durft te sturen.*

<!-- slide 34 -->

### Je zit twee uur vast op dezelfde fout. Wat doe je?

- A. Je vraag uitschrijven met melding, code en wat je al probeerde
- B. Nog een uur doorgaan, anders leer je niets
- C. Een ander deel van de opdracht beginnen
- D. Een dm sturen naar de lector

**Antwoord:** A. Je vraag uitschrijven met melding, code en wat je al probeerde

Uitschrijven dwingt je alles op een rij te zetten, en dat lost het vaak al op. Zo niet, dan staat je vraag klaar om te posten in het kanaal, waar meer mensen meelezen dan in een dm.

<!-- slide 35 -->

### Spiekbriefje

*De volgorde waarin je het aanpakt.*

- **Lees**: Het type, de boodschap, het bestand en de regel. De eerste regel die naar jouw code wijst.
- **Kijk terug**: Wat veranderde je als laatste. Zet het terug, verander één ding tegelijk.
- **Zoek**: De melding zonder je eigen paden, in het Engels, met je versie erbij.
- **Halveer**: Comment de helft weg, print wat er echt in je variabelen zit.
- **Schrijf uit**: Wat wil je, wat gebeurt er, wat probeerde je, welke versies.
- **Vraag**: In het kanaal, met codeblok en volledige melding. En zeg achteraf wat het was.

<!-- slide 36 -->

### Opdracht: Stel één echte vraag

*15 minuten, Alleen*

Neem de laatste fout waar je op vastliep. Ook als je hem ondertussen opgelost hebt, schrijf de vraag alsnog uit.

1. Beschrijf in één zin wat je wil bereiken
2. Plak de volledige foutmelding als tekst, geen screenshot
3. Voeg het stuk code toe dat de fout veroorzaakt, in een codeblok
4. Zet erbij wat je al probeerde en wat je omgeving is
5. Post hem in #help-needed, of hou hem klaar voor de volgende keer

<!-- slide 37 -->

### Verder

*Drie pagina's die je één keer leest en daarna blijft doorsturen.*

- **[nohello.net](https://nohello.net)**: Waarom een bericht met alleen "hallo" iedereen tijd kost.
- **[dontasktoask.com](https://dontasktoask.com)**: Waarom je beter meteen je vraag stelt.
- **[How to create a minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example)**: Hoe je een probleem terugbrengt tot het kleinste voorbeeld.
- **[How to ask a good question](https://stackoverflow.com/help/how-to-ask)**: De handleiding van Stack Overflow, streng maar terecht.

## Begrippen

- **Twintig-minutenregel**: Twintig minuten zoek je alleen, daarna schrijf je je vraag uit. Na veertig minuten stel je ze, want langer blijven zitten levert niets meer op. (slide 7)
- **Badeendje**: Je legt je code regel per regel hardop uit aan iets dat niets van code kent. Bij de regel die je niet kan uitleggen, zit meestal de fout. (slide 8)
- **Foutmelding**: Het type fout (TypeError) met een zin over wat er misliep, en het bestand met regel en kolom. Profile.jsx:12:18 is regel 12, teken 18: daar begin je te kijken. (slide 10)
- **Stack trace**: De regels onder een foutmelding, van waar het knalde tot diep in code die je niet schreef. Sla alles met node_modules of vendor over en zoek de eerste regel die naar je eigen code wijst. (slide 11)
- **Cannot read properties of undefined**: Je leest iets uit een variabele die er niet is. Kijk waar die variabele vandaan komt, meestal een regel hoger. (slide 13)
- **is not a function**: De naam bestaat, maar is geen functie. Meestal een typfout, of een import die iets anders teruggeeft. (slide 13)
- **ENOENT**: No such file or directory: het pad klopt niet. Check de hoofdletters en of je niet een map te hoog zit, of het bestand staat er echt niet. (slide 13)
- **EADDRINUSE**: De poort is al bezet, meestal door een tweede terminal waar je server nog draait. (slide 13)
- **Unexpected token <**: Je verwachtte JSON en kreeg HTML: dat < is het begin van <!DOCTYPE html>. Meestal klopt de url niet en kreeg je een 404-pagina terug. (slide 14)
- **CORS**: Een regel van de browser die het antwoord van een andere server tegenhoudt. Die server moet de header Access-Control-Allow-Origin meesturen, jouw code kan dat niet oplossen. (slide 14)
- **console.log**: Print wat er echt in een variabele zit naar de console. Zet er een label bij, zoals console.log('respons:', data), anders weet je niet welke regel wat toont. (slide 22)
- **Binair zoeken**: Comment de helft van je code weg en kijk of de fout blijft. Zo halveer je het verdachte stuk tot er twee regels overblijven, en daarna zet je alles terug. (slide 23)
- **Minimal reproducible example**: Het kleinste voorbeeld dat de fout nog toont: je snijdt alles weg tot er een tiental regels over zijn. Meestal vind je de fout al tijdens het snijden. (slide 24)
- **Developer tools**: De tools in elke browser, met F12 of rechtermuisknop en Inspecteren. In Console staan je foutmeldingen, in Network zie je welke requests vertrokken en wat er terugkwam. (slide 25)
- **XY-probleem**: Je vraagt hulp bij je eigen oplossing in plaats van bij je probleem, en iedereen helpt je verder op de verkeerde weg. Zeg daarom altijd wat je uiteindelijk wil bereiken. (slide 30)
- **No hello**: Stuur nooit een bericht met enkel "hey" om dan te wachten. Zet je vraag meteen in hetzelfde bericht, dan kan wie tijd heeft meteen antwoorden. (slide 29)
- **Don't ask to ask**: Vraag niet of iemand goed is in css, stel gewoon je vraag. Dan weet wie meeleest meteen of hij kan helpen. (slide 29)
- **#help-needed**: Het kanaal op Discord voor wie vastzit, met meestal binnen het uur een antwoord. Post daar in plaats van in een dm, en zet erbij wat het was als het opgelost is. (slide 32)

## Links en bronnen

### In de presentatie

- [De officiële 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)
