I recently wrapped up 6 months of teaching at General Assembly. I was teaching WDI - a 12 week course that turns beginner programmers into employable junior web developers. It taught me a lot about teaching. One subtle thing I picked up is that we shouldn't talk about magic when we talk to novices.
Novice programmers like to ask questions, but those questions can't always be answered immediately. Either the explanation would be too confusing, or take up too much time, or be a useless distraction. So when the beginner asks, "But how did it know to do that?" we reply "Magic." We say "Magic" because developer culture is tied up with D&D, fantasy novels, and the idea that programmers are mystical and inscrutable. But what we really mean is "Don't worry about it." Rails isn't actually magic. You know that. I know that. The novices know that too1.
But the beginners don't always hear "Don't worry about it right now." Sometimes, they hear "It's beyond everybody's understanding, and we're all OK with that." These brackets and semicolons are confusing to everyone. Just repeat it back phonetically and everything will be fine. You can fix your bugs via trial & error. Nobody understands it anyway.
And that's a dangerous untruth. Programming is entirely understandable: every line, every word, every symbol. Some of the most productive teaching sessions have come from not allowing a student to handwave past some code and insisting they explain how it works, atom by atom. What's this line do? It assigns something to a variable. What's in that variable - what's its type? OK, what did we set it to? That second half, after the plus - what's it doing? Good. Next line.
One half of an instructor's role is imparting knowledge & understanding. The knowledge will come in time if you immerse the students in it, but the understanding will be slower to arrive if students aren't looking out for it. There's a difference between "We don't have to look behind the curtain right now," and "The Wizard is real". the language teachers use should reflect that.
The other half of the job is instilling confidence & self-belief. Programming is hard, technical, confusing work. It gnaws at almost everyone. You have to reinforce that yes, the students are programmers. What they are doing is programming - no matter how much they have to Google for answers and ask for help.
Again, the language you use can reinforce this message. It's better to ask a student "What do you know about [subject]?" instead of "Do you know about [subject]?". The former question is an open-ended chance for the student to show off their knowledge. The latter is often heard as "I have set an arbitrary high standard for your knowledge about [subject]. Do you dare assert that you meet it?". Beginners will always say "No," even if they have encountered it before. You'll quickly find out they do know about [subject]2, but it's still a tiny drag-down instead of a tiny build-up. You can't give people a giant boulder of confidence in one go. You can only give them tiny grains of positive feedback, and trust that one day it will outweigh their self-doubt.
-
The Ruby source code might not know that. ↩
-
"Okay, the thing about frobbing the whatsit is..." "Oh, I know about that, I used that last week." ↩