|
|
|
|
|
by chriszf
5155 days ago
|
|
When you're teaching something completely new to someone, at first you won't even have a common vocabulary. This is true no matter what you're teaching, and you have to dedicate some time to establishing the language (English, not computer). One thing that makes coding a little harder is that many of the analogies we make for non-coders aren't especially clean: A hash is like an set of cubby holes, each can be named and filled, and the set can be infinitely expanded. Packet routing is like trying to find your way from New York to California, only stopping at major cities to ask for a general direction. Memory is like a big sheet of paper, and x = 5 is like writing 5 somewhere on the paper, and x somewhere else, and then drawing an arrow between them. I'm not saying these are the best analogies (or even any good), but I have yet to hear ones that aren't riddled with holes. The average non-coder doesn't have the context to back-fill these holes. As an instructor, you need to realize this and take the time to lay more of a foundation than you think. |
|
I am also worried about the analogies and how they're all slightly wrong. I usually resort to trying to explain exactly what the computer does in completely reductionist terms on the bit level when you write an assignment, print, etc, but it's a bit of a rabbit hole and finding the right balance is hard.