Hello everybody, since this is my first post, let me introduce myself: I'm a research fellow at university of Bologna (Italy) and a "temporary" professor teaching Python programming in a Bioinformatics Master's degree course. I attended Greg's SWC "train the trainers" workshop in London 3 weeks ago.
In my opinion, everything depends on the goal. In a university course, there is much more time to help people who fall behind. In my classes, I try to explain a concept a second time, or even a third (quicker and oversimplified) time if someone still says to be confused by it. Then, if they are only 1 or 2, I move on: there is a class of 25/30 students that need be kept interested in the subject and/or want to get the next piece of information. Those 1 or 2 can catch up later with the help of their colleagues or in office hours with me. In this case, my goal is to keep students with a biological background focused and interested in the subject, while providing useful information. Helping few people may undermine that. A couple of years ago I ran a post course survey, and almost everyone said that the pace was slowed too much by helping a group of 5 students (20% of the class). Since there is no way to know if those lagging behind are just not interested in the course, not doing their homework or having language issues (the course is in English), I switched to "I'll help you later" mode. Last year worked like a charm: only 2 students had trouble passing the exam, and they were those never asking for help (even when encouraged to). In a 1-day Wikimedia workshop we used a different approach. The goal in that case was to help people feeling engaged and let them have fun with wikipedia and other projects. Since the audience was a mixed one (librarians, tech-savvy, people in their mid twenties and people already retired), instead of trying to have everyone walk out with the same competence, we scaled down the tasks for those who had more troubles. In that way, at least they walked away without feeling incompetent and dishearten, and maybe willing to learn more by themselves. However, for the next workshops we planned to have a quick survey during the registration process, then tune the level of the workshop on the skills of the majority and turn down the application requests from those too far from the average. I'm new to SWC, but I think you should have faced similar problems in the past and maybe my examples are not applicable to the current layout of the workshops. Best, Giuseppe Il giorno mar 27 ott 2015 alle ore 15:29 April Wright < [email protected]> ha scritto: > 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 <[email protected] > > 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 <[email protected]> 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 >>> [email protected] >>> >>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >>> >>> >>> >> >> >> ------------------------------------------------------------ >> Dr. Michael (Mike) Jackson [email protected] >> 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 >> >>
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
