On Fri, Oct 17, 2014 at 6:29 PM, Bill Mills <[email protected]> wrote: > Hey Erik, > > Sorry - MCQ == Multiple Choice Question, for doing exactly what you suggest > re: judging where everyone is at in the lecture. I need to work on that too! > Which is sort of the point of my other thread today; what are the barriers > there, what do we need to do to make those techniques actually happen more > in practice? > > Anyway, to stay on Ivan's question: a big +1 to Erik's suggestion, regularly > measuring where students are at is really key. This can also support a > strategy of having your helpers 'bring up the rear', by letting them quickly > see who needs a bit more attention; perhaps leaning more heavily on helpers > can be another strategy for dealing with a really wide class spread.
This is one of the key reasons I've felt that having good helpers has been critical to successful bootcamps. > Along > that theme, another thing to try (pure idea spitball here, haven't done this > myself) would be to take the one or two MOST bored looking students and see > if they can be deputy helpers for the rest of the class. At least once or twice I've had that happen just naturally. But some people might need more encouragement to do that and so I agree it's worth putting out there (like, yes, it's okay for you to step in and help other people if you feel like you can--I guess putting an emphasis on peer learning probably helps with that). Erik > On 2014-10-17 3:11 PM, Erik Bray wrote: >> >> On Fri, Oct 17, 2014 at 4:43 PM, Bill Mills <[email protected]> >> wrote: >>> >>> Really big skill spreads are tough to handle - my thinking these days is >>> to >>> go hard down the peer instruction route; give lots of challenge problems >>> frequently, pace the lecture strongly based on people's responses to MCQ, >>> and give the strong students the challenge of explaining their knowledge >>> to >>> the beginners. >> >> MCQ? >> >> One thing I know I need to work on more in my own workshops is judging >> where everyone is at regularly in the lecture. "Who learned something >> new?" etc. >> >> >>> One thing seems clear: no matter what single fixed lesson anyone comes up >>> with, it's going to hit only one part of the skills distribution; >>> capturing >>> both tails of that wide bell curve requires something more adaptive like >>> peer instruction or project work. I'm eagerly looking for more ideas on >>> this >>> topic! >>> >>> >>> >>> On 2014-10-17 1:33 PM, Ivan Gonzalez wrote: >>>> >>>> Hi everyone, >>>> >>>> I've taught two workshops recently where we run into the same issue with >>>> the shell lesson and I would like to know your thoughts about it. The >>>> shell >>>> lesson is different from the other ones in the sense that you find a >>>> very >>>> broad spectrum of student skills: a big portion of the class knows at >>>> least >>>> a handful of commands, compared to say VC, where people either know the >>>> 10-ish basic commands to work with a repo, or know nothing at all. (I'm >>>> talking all the time of novice level.) >>>> >>>> Both workshops had low attendance (~20), in one case because it was >>>> closed, in the other we don't know yet why. With low attendance, it's >>>> easy >>>> to run in a situation where half of the class is very bored during the >>>> first >>>> three or four chapters of the shell lesson (I found that loops wake up >>>> most >>>> people again.) This puts the whole group in the wrong mood, which >>>> sometimes >>>> is hard to recover from. Pre-assesment surveys are not very helpful >>>> here, >>>> because you can't split such small groups. >>>> >>>> Do you have any ideas on how to fix this? I like the shell lesson and it >>>> had worked well for all-novices groups, but I wonder if someone tried to >>>> adapt to the situation described above by shortening the lesson up or >>>> maybe >>>> making a more-than-novice-but-less-than-intermediate hybrid. >>>> >>>> Best, >>>> >>>> Ivan >>>> >>>> >>>> _______________________________________________ >>>> Discuss mailing list >>>> [email protected] >>>> >>>> >>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >>> >>> >>> -- >>> Bill Mills >>> Community Manager, Mozilla Science Lab >>> @billdoesphysics >>> >>> >>> >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> >>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org > > > -- > Bill Mills > Community Manager, Mozilla Science Lab > @billdoesphysics > _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
