Hi all,
I'm not a SWC instructor but will be applying for the the group training
soon. I share this concern. Here are a few things I've found helpful that
hopefully carry over from my different teaching experience:
1. offering exercises that can be completed at various levels ("Write a
function that takes a function as an argument" is open ended enough that
some students do cool creative things with it, some with prior experience
implement map or reduce, and some type along with me on the projector as we
write a function that calls the passed in function twice) (seconding Bill
Mills on this)
2. making detours for the more advanced folks instead of the beginners.
The mental gymnastics of managing a stack of goals is distracting, so I try
to put that burden on the experienced folks. Explicitly stating that
something is outside the scope of the lesson and then answering an advanced
question or sharing some trivia: in a git seminar experienced users were
happy to go through first commit exercises if I was able to teach them a
new flag that made committing nicer). Hopefully this keeps more advanced
students engaged without frustrating more beginner ones, because this
information is outside the scope of the lesson. (unfortunately it's still
distracting)
3. under-advertising how much material I hope to cover so people aren't
disappointed we didn't get to something if the class moves slowly
4. when asking students to help each other, pushing them over the edge
by assigning pairs or calling out students that can help that can get
students over the hump more quickly. I find students' self-reports of their
abilities inaccurate and problematically skewed so I tend toward "everyone
talk about this with your partner" vs "if you know this explain it to your
neighbor."
5. seeding the class with individuals with whom I have prior experience
and of whom I have good mental models: since I know their prior experience,
I can rely on them to teach background to other and use them as precise
canaries of understanding.
Some techniques that I imagine aren't applicable in the SWC setting that I
ought to write a blog post about instead, based on working at a 3-month
programming retreat:
1. repeatedly *invite people to leave the workshop* at specific breaks
if they feel like they've gotten enough or aren't getting much out of the
session. I announce that I'll run more targeted workshops in a few hours or
the next day, run the same workshop again in a week, or work one on one
later. It takes quite a cultural shift to make this ok.
2. be demanding of prerequisites in the official announcement, then
personally invite people that tend to underestimate their abilities
3. keep class sizes small (less than 12), and if necessary to decrease
class size require prep work (with plenty of time and office hours
available to help people complete it). With a larger class size than this,
I find I can't react much to people being left behind except to try to do a
better job matching the audience and material the next time I teach the
class.
4. invite students to work on something else if we're at an explicit
waiting point, "while I [and the TAs] help everyone get a text editor
invokable from the command line, start playing with HTML as described on
this page" and treat these as breaks
5. provide the blog post / conference talk / video lecture version of
the same information, and when students don't get something play the
session off as an introduction, with more information available later for
self-study
6. Of the six ways to order 3 levels of workshops, I like intermediate,
then beginner, then advanced. This way intermediates can drop down, and
students in intermediate and beginner sessions can also attend the advanced
workshop.
7. have students with more questions stay after (coming early relies on
students estimating their abilities before they've have trouble instead of
assessing whether they actually had trouble)
8. iterating on curriculum to make it have a bare minimum of
dependencies - choosing specially crafted examples that focus particularly
on a single skill without inviting too many questions about underlying
topics to avoid rabbit hole explanations
9. being enthusiastic and welcoming about questions which reveal a
student's lack of background or misunderstanding and being concise and
informative enough in answering them that advanced students learn something
(it's an aspirational goal)
Thomas Ballinger
On Tue, Oct 27, 2015 at 1:19 PM, Azalee Bostroem <abostr...@gmail.com>
wrote:
> Hi Peter et al.
>
> It is great to hear everyone’s thoughts. I would suggest a multi-prongged
> approach:
>
>
> 1. I always post a “Lesson plan” master notebook to the class
> repository. This has my lesson plan in it (so basically everything I plan
> on typing minus the extemporaneous stuff). I point people to this at the
> beginning of the lesson so that students who want to take a lot of notes
> know that the information is already there, students who missed something
> know its there, and students who can’t keep up with the typing can just
> follow along knowing that they can go back to it at their own pace. I also
> let them know that I will post my notebook from class to the repository as
> well for anything that we covered spontaneously.
> 2. I typically bring the class back from exercises when 50-65% of the
> class is finished. I let them know at the beginning of the class that I
> won’t wait for everyone, but that I will go over a solution together as a
> class so that if they didn’t finish, they can see how to finish. I do this
> because I realized that if I wait for everyone, then almost everyone has
> moved onto a different task (often not SWC related) by the time the last
> ones have finished. Explaining to the class my plan and reasoning puts the
> students at ease.
> 3. I like to do an informal poll at the beginning of class to get a
> sense of who may be the more advanced learners. Once they have their hands
> up, I explicitly tell the class - these are your resources, use them.
> 4. I haven’t tried this, but I think it would be useful for
> engagement, especially in a particularly split class - pair up an advanced
> student and a beginner students and have them work together. Make sure the
> beginner student is getting the opportunity to ask questions and
> understands what is going on (maybe encourage them to trade off who is
> typing the exercises). Explicitly assigning people to each other might make
> it easier to ask for help and to feel comfortable offering help.
>
>
> -Azalee
> -------------------------------------------------------
> K. Azalee Bostroem
> Graduate Student
> UC Davis
> http://azaleebostroem.wordpress.com
> -------------------------------------------------------
>
>
>
>
> On Oct 27, 2015, at 9:38 AM, Bill Mills <mills...@gmail.com> wrote:
>
> I stretch the skill-level bracket of all my workshops by leaning heavily
> on tiered challenge problems; I break for problems regularly (every 30
> minutes or so, giving those really struggling a chance to catch up), and
> set 'baseline' problems (that everyone is expected to solve) and 'stretch'
> goals - harder problems that the intermediates can derive value from.
>
> On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross <noam.r...@gmail.com> wrote:
>
>> One thing that I've found is that students who are behind sometimes give
>> up trying to type along and just read along with the lesson notes. While
>> it's not the ideal outcome, it may be the best one for some fraction of
>> students, and this makes it easier for those students to reference those
>> notes at some later time. So it might be worthwhile to point students to
>> each lesson's notes before starting that section.
>>
>> On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown <ctbr...@ucdavis.edu>
>> wrote:
>>
>>> Hi Amanda et al.,
>>>
>>> thanks, this is a nice discussion!
>>>
>>> I try to distinguish between "zero entry" and more advanced workshops
>>> as clearly as possible, but of course problems happen in both directions
>>> for the advanced workshops - too advanced, and too beginner.
>>>
>>> One strategy that (I think) Greg suggested a long time ago was to suggest
>>> that the too-advanced people help out with the too-beginner people when
>>> a TA wasn't available. Of course this can go wrong as well, but I think
>>> when it goes well it's quite nice.
>>>
>>> cheers,
>>> --titus
>>>
>>> On Tue, Oct 27, 2015 at 03:46:12PM +0000, Amanda Charbonneau wrote:
>>> > I actually had a similar problem, but with an intro workshop that I had
>>> > already pared down considerably because I knew the learners were skewed
>>> > towards *very* beginners. Even with the simplified material, I had a
>>> > handful of people who couldn't keep up, people who had to hover a
>>> single
>>> > finger back and forth over the keyboard to locate each letter.
>>> > This handful of people comprised about a quarter of the attendees, and
>>> > the advertising clearly said that the course was for learners who have
>>> > little to no prior computational experience, so they hadn't really
>>> gone to
>>> > the wrong course level. It was just that their interpretation of no
>>> prior
>>> > computational experience was very different from what SWC expects. It
>>> felt
>>> > wrong to just press on without them, so I slowed everything down to a
>>> > crawl, but I also felt extremely bad that we only got partway through
>>> any
>>> > of the material.
>>> >
>>> > Sorry I don't have a solution, just commiseration.
>>> >
>>> > -amanda
>>> >
>>> > On Tue, Oct 27, 2015 at 11:24 AM Peter Steinbach <
>>> steinb...@scionics.de>
>>> > wrote:
>>> >
>>> > > Hi April,
>>> > >
>>> > > thanks for your insights. As a matter of fact, in my case the local
>>> > > organizers were very forthcoming and implemented a pre-assessment
>>> form
>>> > > before the workshop. Still, I had the feeling during the workshop
>>> that
>>> > > this pre-assessment only covered the tip of the iceberg (as
>>> expected).
>>> > >
>>> > > I guess the trade-off who to bore and whom to carry through is
>>> always on
>>> > > the plate of the instructor. I'd have to say that being in a team of
>>> 2
>>> > > helps at this point tremendously as the co-instructor is among the
>>> > > "students" and simply can assist here and there.
>>> > >
>>> > > If people have more feedback on the matter, I am happy to hear it. If
>>> > > not, my gratitude to those that replied already.
>>> > >
>>> > > Best,
>>> > > Peter
>>> > >
>>> > > On 10/27/2015 03:27 PM, April Wright wrote:
>>> > > > Hi Peter-
>>> > > >
>>> > > > I've been in this exact same situation, though with a departmental
>>> > > > workshop, rather than an SWC one. It's hard, and I'm sorry that
>>> happened
>>> > > to
>>> > > > you.
>>> > > >
>>> > > > Since you're SWC, I think the first thing to do is ask the host.
>>> Often,
>>> > > the
>>> > > > host has some specific ideas about what they want the learners to
>>> come
>>> > > away
>>> > > > with, and that can help you steer the course.
>>> > > >
>>> > > > What I did, in practice, was this: I spent way too much time
>>> helping
>>> > > > novices. I slowed down, got through less than half of the
>>> material, and
>>> > > the
>>> > > > intermediates, who had actually chosen the correct class and paid a
>>> > > nominal
>>> > > > fee for it were very unsatisfied. I really think that I made the
>>> wrong
>>> > > call
>>> > > > by punishing people who carefully read the sign-up and
>>> prioritizing those
>>> > > > who didn't. There are a lot of resources out there to help people
>>> take
>>> > > the
>>> > > > first steps in programming. There are fewer to help with the
>>> 'what's
>>> > > next',
>>> > > > and I should have been more sensitive to that fact. What I should
>>> have
>>> > > done
>>> > > > is told people who were working on novice-level skills that they
>>> were
>>> > > > welcome to stay and work, but that people working on the course
>>> material
>>> > > > would be assisted first.
>>> > > >
>>> > > > On the next go around, I added a list of skills the learners
>>> needed to be
>>> > > > comfortable with to attend (previously, it had simply been a link
>>> to the
>>> > > > previous workshop) and a code snippet one of the students had
>>> written. I
>>> > > > let them know that this was the level of familiarity they needed
>>> to have
>>> > > *with
>>> > > > Python* to attend, and that TAs would preferentially assist those
>>> who
>>> > > were
>>> > > > mastering course skills over those who were mastering other
>>> material.
>>> > > >
>>> > > > That worked, I only had one person for whom the course was
>>> inappropriate
>>> > > > (they were too high level) show up.
>>> > > >
>>> > > > --a
>>> > > >
>>> > > > ---------
>>> > > > Postdoctoral Researcher
>>> > > > Iowa State University, EEOB
>>> > > > University of Kansas, EEB
>>> > > > 251 Bessey Hall
>>> > > > Ames, IA 50011
>>> > > > 512.940.5761
>>> > > > http://wrightaprilm.github.io/
>>> > > > <http://wrightaprilm.github.io/pages/about_me.html>
>>> > > >
>>> > > >
>>> > > > On Tue, Oct 27, 2015 at 8:23 AM, Michael J Jackson <
>>> > > micha...@epcc.ed.ac.uk>
>>> > > > wrote:
>>> > > >
>>> > > >> Hi Peter,
>>> > > >>
>>> > > >> If there are more people falling behind than you have helpers to
>>> handle,
>>> > > >> then I'd just slow down. I'd (reluctantly) rather bore those who
>>> don't
>>> > > want
>>> > > >> a slower pace, than confuse those do.
>>> > > >>
>>> > > >> cheers,
>>> > > >> mike
>>> > > >>
>>> > > >>
>>> > > >> Quoting Peter Steinbach <steinb...@scionics.de> on Tue, 27 Oct
>>> 2015
>>> > > >> 11:39:01 +0100:
>>> > > >>
>>> > > >> Hi Raniere et al,
>>> > > >>>
>>> > > >>> thanks for the pointers for recording the terminal history, I'd
>>> like to
>>> > > >>> get back to my more general question though ... how to give
>>> > > participants
>>> > > >>> that are not up to the level of the course a chance to follow? I
>>> don't
>>> > > >>> wanna drag them all through, at some point there has to be a
>>> limit for
>>> > > the
>>> > > >>> sake of the remaining crowd. But still, I'd like to hear people's
>>> > > >>> experience on this.
>>> > > >>>
>>> > > >>> Best,
>>> > > >>> Peter
>>> > > >>>
>>> > > >>> On 10/27/2015 11:23 AM, Raniere Silva wrote:
>>> > > >>>
>>> > > >>>> Hi Peter,
>>> > > >>>>
>>> > > >>>> Could you share these scripts?
>>> > > >>>>>
>>> > > >>>>
>>> > > >>>> Please check
>>> > > >>>>
>>> > > >>>>
>>> > >
>>> https://github.com/swcarpentry/site/pull/1124/files#diff-9e17f2fd404c84648654a4fc54a9a2ecR71
>>> > > >>>> .
>>> > > >>>> We are going to publish it this week.
>>> > > >>>>
>>> > > >>>> I'd like to see if they'd capture a nano screen etc
>>> > > >>>>> (I presume not, but I'd like to try them anyhow).
>>> > > >>>>> Apologies if they were already shared with this community and I
>>> > > >>>>> overlooked them.
>>> > > >>>>>
>>> > > >>>>
>>> > > >>>> There are terminal screen recorder that can capture nano
>>> > > >>>> but from my experience they don't work for what you want. =(
>>> > > >>>>
>>> > > >>>> Cheers,
>>> > > >>>> Raniere
>>> > > >>>>
>>> > > >>>>
>>> > > >>> --
>>> > > >>> Peter Steinbach, Dr. rer. nat.
>>> > > >>> HPC Developer, Scientific Computing Facility
>>> > > >>>
>>> > > >>> Scionics Computer Innovation GmbH
>>> > > >>> L??scherstr. 16
>>> > > >>> 01309 Dresden
>>> > > >>> Germany
>>> > > >>>
>>> > > >>> phone +49 351 210 2882
>>> > > >>> fax +49 351 202 707 04
>>> > > >>> www.scionics.de
>>> > > >>>
>>> > > >>> Sitz der Gesellschaft: Dresden (Main office)
>>> > > >>> Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial
>>> Registry)
>>> > > >>> Ust-IdNr.: DE813263791 (VAT ID Number)
>>> > > >>> Gesch??ftsf??hrer: John Duperon, Jeff Oegema (Managing Directors)
>>> > > >>>
>>> > > >>> _______________________________________________
>>> > > >>> Discuss mailing list
>>> > > >>> Discuss@lists.software-carpentry.org
>>> > > >>>
>>> > > >>>
>>> > >
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>> > > >>>
>>> > > >>>
>>> > > >>>
>>> > > >>
>>> > > >>
>>> > > >> ------------------------------------------------------------
>>> > > >> Dr. Michael (Mike) Jackson m.jack...@epcc.ed.ac.uk
>>> > > >> Software Architect Tel: +44 (0)131 650 5141
>>> > > >> EPCC, The University of Edinburgh http://www.epcc.ed.ac.uk
>>> > > >> Software Sustainability Institute http://www.software.ac.uk
>>> > > >>
>>> > > >>
>>> > > >> --
>>> > > >> The University of Edinburgh is a charitable body, registered in
>>> > > >> Scotland, with registration number SC005336.
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> _______________________________________________
>>> > > >> Discuss mailing list
>>> > > >> Discuss@lists.software-carpentry.org
>>> > > >>
>>> > > >>
>>> > >
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>> > > >>
>>> > > >
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > Discuss mailing list
>>> > > > Discuss@lists.software-carpentry.org
>>> > > >
>>> > >
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>> > > >
>>> > >
>>> > > --
>>> > > Peter Steinbach, Dr. rer. nat.
>>> > > HPC Developer, Scientific Computing Facility
>>> > >
>>> > > Scionics Computer Innovation GmbH
>>> > > L??scherstr. 16
>>> > > 01309 Dresden
>>> > > Germany
>>> > >
>>> > > phone +49 351 210 2882
>>> > > fax +49 351 202 707 04
>>> > > www.scionics.de
>>> > >
>>> > > Sitz der Gesellschaft: Dresden (Main office)
>>> > > Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial
>>> Registry)
>>> > > Ust-IdNr.: DE813263791 (VAT ID Number)
>>> > > Gesch??ftsf??hrer: John Duperon, Jeff Oegema (Managing Directors)
>>> > >
>>> > > _______________________________________________
>>> > > Discuss mailing list
>>> > > Discuss@lists.software-carpentry.org
>>> > >
>>> > >
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>> > >
>>>
>>> > _______________________________________________
>>> > Discuss mailing list
>>> > Discuss@lists.software-carpentry.org
>>> >
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>>
>>> --
>>> C. Titus Brown, ctbr...@ucdavis.edu
>>>
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss@lists.software-carpentry.org
>>>
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>>
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>>
>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>
>
>
>
> --
> Best Regards,
> Dr. Bill Mills
> TRIUMF
> _______________________________________________
> Discuss mailing list
> Discuss@lists.software-carpentry.org
>
> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss@lists.software-carpentry.org
>
> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>
_______________________________________________
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
