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.