On Sun, Mar 06, 2016 at 05:41:12PM +0000, Code, Warren wrote: > … the Kirschner, Sweller, and Clark article [3 in Trevor's comment] > can be a bit of a tricky entry point into the literature…
Better (ideally open) entry points are welcome ;). It looks like there is more good stuff and a number of references in [1], although that lacks a DOI, clear author information, and possibly peer review. > For the SWC lesson provided as an example here, there was certainly > substantial guidance [snip scaffolding] they were asked to practice > the kinds of things that people encounter in scientific computing > (dealing with unknown data files, grappling with unexpected bugs, > etc.) and had relatively on-demand support from the helpers and > other participants. I agree on the potential for good scaffolding, although it's easy for an hour of student-lead exercises to end up being “throw them into the deep end” instead of “the shallow end of the pool is over there, instructors will be circulating, and lifeguards are standing by for anyone that calls out or looks distressed”. I think Giuseppe's: * “by themselves” in the subject, * “some were stuck at the first [problem]” and “forced to think about the problems they were facing and to ask for help” in the body. gave me the impression that this workshops dispensed with the circulating instructors and just kept the lifeguards. For some people that will be fine. But folks are probably in a face-to-face SWC workshop because they're not comfortable working through the SWC lessons (or other online tutorials) on their own, so I think it's useful to have more instructor/helper-initiated interaction. > [snip reasonable thoughts about scaling practice periods with > exercise complexity]. If there is a widespread difficulty that > isn't terribly interesting to the main ideas, like the GUI bugs, > maybe having a shorter cycle of "try this - did everyone get this > error - this is why, there's this bug" would be warranted before the > longer period working alone. In my experience, the only practical > way to discover these sort of difficulties is to run the lesson, > collect that sort of information, and do it differently the next > time. :) I'd certainly recommend avoiding known library/tooling bugs in the first two days that folks are coding. The existing SWC lessons are fairly narrowly scoped (e.g. see the “other 90%” phrasing [2]), and a tool with novice-noticeable bugs in the most fundamental 10% is probably not a good tool to introduce to novice programmers ;). But yeah, sometimes it's not clear that a particular exercise will be confusing until you put it in front of people, so +1 on emphasizing evolutionary lesson polishing. Cheers, Trevor [1]: http://www.deansforimpact.org/the_science_of_learning.html https://github.com/swcarpentry/instructor-training/blob/58c6942bc6d910d7f886098c231b4d107c9ff0c3/papers/science-of-learning-2015.pdf Deans for Impact (2015). The Science of Learning. Austin, TX: Deans for Impact. [2]: https://github.com/swcarpentry/python-novice-inflammation/blob/v5.3/instructors.md#overall -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
