Teaching basic lab skills
for research computing

2015 Post-workshop Instructor Debriefing, Round 3

We had our third post-workshop debriefing of the year yesterday, in which we discussed several recent workshops. The most important point was probably that workshops are running more smoothly today than they did a year ago, even for first-time instructors.

Our Tulane workshop was taught in R; about 50 people registered, and about 40 showed up. The crowd was mostly biomedical, and the instructors use the Gapminder dataset throughout. R was taught in 2 half day sessions, an introduction to R and advanced R.

The biggest innovation was echoing all commands via Dropbox: the R scripts being edited were all saved to the Dropbox folder, so learners could follow along in real time. More importantly, the helpers could follow along as well, and catch people up when they fell behind. The workshop also got as far as showing people ggplot2 and knitr in the second session, though this was more a case of "look at the cool things you'll be able to do" than a lesson.

The workshop in Illinois was slightly smaller—about 30 people. Most were aerospace, chemical, and materials engineers, with a few biologists and geologists along to liven things up. As one of the instructors described in an earlier post, they collected feedback at every break, and took 5-10 minutes at the start of each session to address issues raised before pressing on. All instructors took part in sorting the feedback (which was handed in on sticky notes) so that instructors who were going too fast or into too much detail could see that for themselves.

The workshop at Sick Kids Hospital in Toronto used R again. The lead instructor felt it didn't hit everybody's expectations, mainly because there were so many different expectations: some people had a lot of prior programming experience, and were there to learn the statistical packages in R, while others needed help with basic ideas like loops. One thing that went really well was the introduction to R factors and different ways of addressing data in a data set: by the end of the workshop, some learners were using very complex techniques for manipulating their data.

Thomas Guignard taught at both SUNY Albany and the University of Toronto He commented that he's not comfortable ad libbing in front of learners, so he could defer difficult questions, figure out the answer during the break, and then come back to them when students were back in their seats. He also commented that several of the attendees at the Toronto workshop had installed Python 3.4 instead of Python 2.7, which led to more than a little confusion. (We have since added notes to the installation instructions to clarify which version people should get.)

A couple of points were made about teaching with the IPython Notebook. First, it doesn't show as much history on screen at one time as (for example) the Bash shell, so it's harder for learners to follow what's going on. Second, Neal Davis said that he found it much better to start with an empty notebook and grow it cell by cell rather than opening up one that already had code in it and replaying it.

Finally, we had a brief discussion (again) of whether we ought to follow Data Carpentry's lead and have a single data set or example run through all of the lessons. I've resisted doing this in the past, since it makes it harder for instructors to mix and match material, but I now believe the benefits outweigh the drawbacks. We will discuss this at an upcoming lab meeting, along with ways of getting notes like these into the instructor's guides for the lessons.

Dialogue & Discussion

You can review our commenting policy here.