-
Notifications
You must be signed in to change notification settings - Fork 13
Instructor Toolkit for Facilitation
When a student needs to come to a specific conclusion, consider using "think, pair, share."
- Think: Give them individual time to consider a solution themselves. This should be on the shorter end (long enough to come to at least one conclusion)
- Pair: Ask them to discuss in small groups
- Share: Discuss in large groups
Correctly determining the "true question" of a question of a learner can help save time and breath.
As much as your skills and context and resources allow, do your best to see if learner's question is "actually" one of the following.
| Possible "true question" | Possible response |
|---|---|
| What is the syntax for a specific case? | Give them the syntax, and compare to "typical syntax" or common syntax if relevant, to explain why this may stand out. Give them a rule/pattern to follow so they know when to use that syntax. |
| Why is the syntax like that for a specific case? | Give them a reason for either how this syntax is related to/extended from a different, recognizable syntax, or briefly touch on the out-of-scope discussion. |
| What does this specific concept mean? | Give them a definition, then give an analogy/metaphor/illustration or example in code, and then repeat the definition. |
| When do we care about that specific concept? | First, recontextualize the appropriate level of abstraction for this concept (remind them: are we talking about code? Design? Software Development Teams? The Tech Industry?). Then, give them a pattern or analogy for this concept. Then, restate the definition of that specific concept, and summarize. |
Push a student from questions like "I have a question on X." or "Could you go over Y?" or "I am a little fuzzy on Z." to more concrete questions.
More specific questions can help...
- Students practice their question-asking skills
- Students understand their own question and what answer they're looking for
- Help facilitators/question-answerers understand when they've answered the question
Push for questions that literally start with...
- Who
- What
- Where
- When
- Why
- How
Someone who "just wants the answer" is either...
- feeling frustrated, impatient, or simply disinterested in the topic
- feeling pressure from time
Both motivations are valid, and both are stress or trauma responses worth of patience, respect, and honor.
As facilitators, we are typically either tempted to...
- provide a specific answer to solve a specific problem
- provide an explanation
Using your best judgment, it is possible to give a student both an explanation and a specific answer.
Using your best judgment, pick one to "speed through," and one to "slow down on."
Using your best judgment, pick one to go first, and tell the student your plan first. Setting expectations allows an impatient student to stay engaged throughout your entire explanation. Examples include...
- "I will give you a brief explanation first, and then dive into how to solve your problem in code."
- "I will give you a long explanation, and at the end I'll show you how to do it in one line."
- "Let me give you the quick answer, and then let me give you a long explanation."
- "Let me dive straight into this code and spend time there, and afterwards I'll relate it back to the concept."
Obviously, don't say both if it isn't the right thing to do.
Human brains are great at recognizing patterns!
We can help learners learn often by turning concepts into recognizeable rules and patterns that follow the format "When , Then ."
Turning concepts into rules and patterns...
- Does not/should not detract from the need for learners to learn formal definitions
- Reduces the unnecessary mental load on learners on how new the concepts are.
- Learners should spend their time recognizing patterns and recognizing their strengths and weaknesses in curriculum mastery.
- Recognizing patterns is more similar to the occupation of programming, and how programmers simply learn enough programming to recognize patterns!
- Reinforces the curriculum value that we do not know everything and are okay with not knowing everything.
- Gives power to the learner by giving them something to actively observe and a clear next step.
Teaching someone how to read code/recognize syntax can be really useful to teach in pattern recognition. Ex. "When I see trip.connect(passenger), I see .(), or <X> dot <Y> parens <Z> parens . When I see that pattern, I associate it with calling something calling a method, because of the dot and the parens."
This kind of teaching and learning mimics how spoken/written languages are often taught, and is already very compatible with how social humans learn! This also reinforces:
- learners reading code without skipping lines or skimming
- learners practicing communicating about code
Teaching someone "how to think" about a problem can be:
- Tell someone what they want
- Then tell them how to get what they want
There are plenty of ways to go past reciting definitions.
Writing code is the obvious and one of the best ways to get past "definitions."
Unlike learning how to read a first language... Reading code to a newbie developer is an advanced skill that takes months of practice. Following the flow of execution is challenging and unintuitive to non-programmers.
Reading code is not about reciting definitions. It is about recognizing patterns and applying knowledge about syntax. It requires understanding of systems and interactions! Code tells stories, and cannot be known or learned, but must be read, like a novel or poetry, with recognizing a beginning, middle, and end.
We can assess reading by:
- spending time following code line-by-line
- spending time forming sentences and practicing vocabulary line-by-line. Line-by-line is important, as opposed to "summarizing a block of code at a time." Line-by-line reinforces the flow of execution (loops, frames, etc). Summaries of code allow students to skip over details.
- asking students to describe the responsibility of a line of code or a block of code
- asking students to create poetry, prose, paragraphs, drawings, skits, presentations, or lessons about code
- asking students to teach someone about code
Using the phrase "Explain Like I'm 5" pattern humbles everyone's position to learners, and allows students to empathize.
"Explain Like I'm 10" may be a literally more reasonable request.
this is the same as ELI5 but implies a research portion
boxes and arrows are awesome!!!! boxes are things!!!! (systems! apis! dbs! classes! people! teams!) arrows imply "source" and "direction" and connection!!!!! that happens a lot in programming!!!!
use a whiteboard!!!!!
tell them to use a whiteboard!!!!!
when a facilitator takes a typical syntax example and replaces the variables with something weird, it helps connect variables/concepts better, and also makes it more memorable!!
tell them to take a coding example and make it personal and watch it break or not break!!!
unless you make a comic or studied sequential art, diagrams and pictures and code lack sequence :O
skits help people remember "first this happened, then that happened!"!! that's great