Other Pages

Expand All

teaching_tips.md

## General Teaching Advice

When planning, don't think about what _you're_ going to do. Think about what _they're_ going to do.


## Metaphors and Stories for Teaching Programming:

A program is like a recipe. There's two parts: a list of ingredients and a list of instructions. Think of code as the instructions and data as the ingredients. 

Also, to extend the metaphor, think about doubling a recipe: the instructions don't change even though the data are different this time.

Computer memory is like a warehouse with lots of boxes. Each box has something inside (the data) and it also has a label (the variable name).

The command line as Zork. You are "in" a room (a directory) and can either act on things in the room (commands) or move to a new room (cd). It's very important that you know where you are! Learn how to read the command line, and do an "ls" (or "dir") to look around.

# Notes
* Have one volunteer be a runner to remind people when it's 10 minutes until the next break. (This worked really well.)
* Make sure all of the projectors have Mac adaptors
* Handouts with all of the code that people need to type
* Tell people at the beginning that the slides are online
* Have a volunteer leader, make sure they are distributed evenly
* Advertise that the Friday night setup is **required**, send notes out 1 week ahead of time, so people can get started ahead of time
* USB keys and/or DVDs with the big stuff like XCode
* Ask the venue about bike policy (can participants bring bikes inside?) and communicate that to participants ahead of time.
* Get a good night's sleep before the class, it is important to be well rested and fresh when teaching or TA'ing.
* Start with live coding - watch and type along, don't even use slides. make sure students & teachers irb prompts display line numbers, so we can say go to line 32
* Go into IRB to practice basic concepts first, don't discuss what agile and a variable is in the abstract right away. Learning by doing first and talking later worked better.
* At the very beginning, show a designed version of app so people can recognize it as finished product like other web sites they see: screenshots are on Sarah Allen's site.
* Have TAs wear different badge colors so they can recognize each other.
* Discuss rubyisms where appropriate. use code to show elegance & readability of ruby vs other languages: each vs (for i; i = "lame"; i ++)
* Ask students to discuss what they learned, what they thought of it, at end of the day. As beginning of wrap-up session or just before it.