More thoughts on my recent 12 hours of Software-Carpentry-inspired teaching: one feedback card that I will keep in my rainy-day folder said the learner liked my jokes.
The jokes came in after the second break on the first day, before I figured out that 15 minutes was the right length for the break. I was trying to bring the group back together after only 5 minutes off, and having trouble. “Knock knock,” I said, not too loudly. “Who’s there?” answers some handful of learners who heard me over the racket. Now the room was starting to focus on this. But what did I have to deliver? “Isabel,” I offered, thanks to my 7-year-old neighbor.
Do you know this one? I need to get some Python-relevant material for future courses. Anyway, more of the class was now working with me on it. “Isabel who?” they politely offered. “Is a bell necessary on a bicycle?” Definitely a winner… you never know what will go over until you try it on stage.
I’ve recently completed 12 hours of teaching Introduction to Python and SQL for an audience of new Institute for Health Metrics and Evaluation (IHME) staff and fellows. SWC is a gem! (I have been thinking this for a while.)
In retrospect, what worked and what might I do differently next time?
Some SWC mechanics that worked well: Live coding, Hands-on exercises, Sticky notes, Jupyter notebooks, and friendly teaching assistants.
Some things to change: Remember to give the big-picture framing for each section, Do more explanation of solutions after hands-on exercises, Share the syllabus ahead of time, and emphasize that this is *introduction* material.
Some changes that I made mid-stream: longer breaks (15 minutes every hour or so), connect the examples to IHME-specific domains.
I also did not use an etherpad until we got through Creating Functions (Section 6 in the Python Inflammation Lession). That might have been too much typing in the first two sessions, and it was definitely appreciated.
I have been a fan of this educational offering for a while now, and I have been mentioning that for a while now, too. But I am moved to say it again, because I’m planning a four-session Intro to Python training for aspiring Health Metrics Scientists, and the SWC curriculum is making that so easy. It could have been so hard. ❤ u SWC.
I greatly enjoyed a recent Software Carpentry (SWC) training that I attended. It was on training trainers, and had a ton of useful information.
One thing that it included, which has stuck in my mind is a “code of conduct”, which SWC has for all workshops. [link]
I like the way it incorporates humor; this also actually help me think of it, because I made a conscious choice _not_ to make fun of certain text editors twice during the two day workshop (despite the hilarious joke that I had to refrain from telling).
A question though: how to do? Just putting on the webpage is a little too little, perhaps, but reading the whole thing at the beginning of the workshop is too much for some instructors. I thought the approach we took was a bad compromise, reading some and saying that it existed. It could be good, but it could come off like this is something required that the instructors do to tick the box “we broadened participation”.
What about having the text projected at the beginning of the session, so while people are coming in and settling down, they can read it at their own pace. It needs to be projected in a readable font, which might be a technical challenge, since it is long. And anyone who shows up late will miss it. (I showed up late, maybe I missed it…)
This Software Carpentry project to find out how people are testing their scientific code looks great: http://software-carpentry.org/blog/2014/11/close-enough-for-scientific-work.html
I’ll have to keep my eye on the associated GitHub page https://github.com/swcarpentry/close-enough-for-scientific-work
A cool experiment from the Mozilla Science Lab: Code Review for Scientists. I look forward to the results.
If anyone wants to do code review of my science, you can comment line-by-line on my github repos.
I’m quite taken with the Software Carpentry approach to teaching scientists computer skills, especially since I saw it in action in UW a few months ago. One aspect that I’ve been trying out for my own course is the “mastery table” approach that the Software Carpentry Instructor Study Groups use. Here is a mastery table for teaching version control. I have made a few of my own, but I don’t think I said enough for any novice to leave competent, according to my ambitions. I will keep trying.
I’m spending yesterday and today helping out with a two day software carpentry workshop at UW.
Software Carpentry helps researchers be more productive by teaching them basic computing skills. We run boot camps at dozens of sites around the world, and also provide open access material online for self-paced instruction. The benefits are more reliable results and higher productivity: a day a week is common, and a ten-fold improvement isn’t rare.
I am impressed by the curriculum and by the attention to evaluation, not an easy task in any educational setting. The 20% productivity increase is an interesting claim. From what I observed yesterday, I would expect huge heterogeneity based on past experience, and I would expect this heterogeneity to be hard to predict.