@futurebird

Okay, last bits, sorry for going on so long!

1. My inspiration was Software Carpentry's module on reading errors. https://swcarpentry.github.io/python-novice-inflammation-2.7/07-errors.html
2. I also taught them about 'rubber ducking'. Made it all conspiratorial, let them in on the secret, tell them the pros do this. (We do!) The secret is: draw a little duck, and when you get errors explain your problem to the duck. Duck is simple duck, so explain every detail. Often, because you explain it, you'll realise how to fix it! 4/4

@futurebird

Also IndentError, KeyError, and IndexError.

(Optional: 'hunt the Big Five': can they deliberately make code that has this error? and then fix it?)

Finally TypeError, for which more than the previous errors the fix depends on what you were doing. New phrase: 'I THOUGHT I had a number, but I HAVE a string. Can I change what I HAVE, or should I change what I THINK?"

Change what I have: int(my_string)

Change what I think: Ah, x can also be a string. `if type(my_x) is str: ...`
3/

@futurebird
So that was step one, teach their eyes to pick info from the error text, instead of sliding off it. Next step teach them to see error as a call for their action. I did this by running through 2-3 common errors and the action, repeating 'WHEN I see an X error, THEN I do Y' language.

WHEN I see a NameError, THEN I read the error, look up the line, and look for a mistyped name.

WHEN I see a SyntaxError, THEN I double-check my quote marks / parentheses / colons.

2/

@futurebird Yes, when I taught young adults I had an explicit section, right after the first ones that gave them a taste of success, on reading error messages.

Showed an error -- intimidating, eh? But we can pick out parts. Line number, file, error type, message, and a traceback. Highlight those as I pointed them out. New raw error message: hey, same structure! Can we pick out the line number? etc.

1/