Hi Giuseppe, Without knowing all the details, this sounds a little dangerous to me. I think independent work is very valuable, but that assumes that everyone is properly prepared. One key thing that I try to do while instructing and helping is to ‘be available.’ In my experience (and as I was trained) a lot of people will not openly indicate they need help (even as seemingly innocuous as putting up your red sticky). But how many times you been teaching and someone has pulled you aside? If I recall in the literal sense, people who are drowning aren’t flailing their arms and screaming - the same may be true for instruction.
If learners were properly prepared, the amount of independent work can increase in length as they become experienced (I would not leave first-time cmd line users alone for an hour!). Independent work should also have some guidelines that encourages learners to work through problems together. Instructors can also help to keep the room in synch by giving helpful hints when several people are getting stuck at the same point. Outgoing learners who are comfortable can also be encouraged walk others through how they solved things. The most dangerous thing (IMHO) is to avoid any perception by learners who you’ve just met that you are going to be hands-off in the back of the room sipping Ovaltine. It can discourage learners and perpetuate the idea of an aloof know-it-all. Just my reactions – my description might be totally the opposite of how the workshop went. It’s 11PM, so this is totally instinctual, but glad for anyone’s references that refute or support some of these hunches. - Jason From: Discuss [mailto:[email protected]] On Behalf Of Giuseppe Profiti Sent: Wednesday, January 27, 2016 7:34 PM To: Software Carpentry Discussion <[email protected]> Subject: [Discuss] Leave students by themselves during hands-on Dear all, during a recent training course (not a SWC, but we used many of its techniques while showing how to use few software for analysis), we had many trainers and some of them had an approach to exercises that I found strange. After the course we discussed that, since I was interested in their point of view. The lesson was something like that: less than 1 hour of explanation, then exercises were presented and the students had 1 hour or a bit more to complete them. Using colored stickers, students could attract our attention when they needed help. I was a bit skeptic about this approach: the students had no clue about the content and the format of the input file provided, some of the steps required knowledge about a couple of bugs in the software UI, and there was no explanation on the expected output (or on the meaning of the output, when there was more than one result). Also, given the length of the session there was no way to adjust their pace: few finished almost all the exercises, some were stuck at the first one and so on. However, another trainer pointed out that in this way the students were forced to think about the problems they were facing and to ask for help. In my opinion, while error messages or wrong results are good for learning (i.e. by showing an error message it is possible to explain the importance of reading them to understand the problem, while running a software with wrong settings is useful to introduce new parameters and options), I found that frustration may be the most probable outcome. Also, explaining the correct usage of a (bugged) software to each single person that asks for help may be a waste of time. Since the strategy of splitting the presentation in short chunks, exercise often nad build from previous results is something I fell more familiar, I would like to know your opinions about that. Thanks in advance for your help. Best, Giuseppe -- Adjunct professor - International Master's degree in Bioinformatics Post-doctoral Research Fellow - Biocomputing Group University of Bologna, Italy
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
