This week I taught my first Software Carpentry workshop at Oklahoma State University. The workshop had been in such demand that we had a total of four instructors, including Jonah Duckles, Kate Hertweck, Thomas Guignard, and myself. I arrived at the hotel close to 2am the first day of the workshop, and was running on nespresso during most of the morning session.

Though originally Thomas and I were set to teach one room together, due to flight troubles Jonah took over the session on the Unix shell that kicked things off. I spent most of the time fixing issues with GitBash (usually fixed by reinstalling it) and helping people connect to the network (curse those certificates!), but these issues didn’t affect most of our learners. I was able to spend at least a little time watching Jonah teach, too, and I can say I learned a few things myself (e.g. that tr is a thing!).

I taught the session on Python, which was split into two parts over the two days. This decision was made at the cost of omitting SQL for Day 2. It worked out well because even though I went too fast the first day (this was the dominant complaint from feedback), we still only barely touched on functions by the end of it. The second day’s session was entirely filled by the second half of material, which built on that of the first.

This was my first time teaching the SWC Python lesson, and since it’s become an indispensable tool for doing my own research, I made use of the iPython Notebook. To help combat the problem of learners getting behind and needing to see content that I’ve since scrolled past, I did all my work out of a Dropbox folder and shared a link to my notebook file on the etherpad. Although a good idea, the biggest problem was that most learners couldn’t figure out how to view the file, since downloading and clicking on it usually results in it being opened in a text editor (they’re JSON files), leading to more confusion than answers. What’s more, it’s hard for many learners to find their working directory (where they’re working in a GitBash / terminal shell session) in the graphical file manager, so telling them to download the file and move it to the directory their notebook session is running from results mostly in blank stares.

Fortunately one of our helpers added the notebook link to NBViewer, which renders the notebook directly in the browser so the students didn’t need to bother with the file at all. This required some fiddling to ensure that NBViewer actually picked up the updates whenever I saved my working notebook, but otherwise it worked extremely well. The students very much appreciated being able to click the nbviewer link in the etherpad and view my entire running notebook, hitting refresh to see it as it updates. I should note, however, that the time between me saving and the updated notebook showing up on refresh was at least a couple minutes; Thomas did some troubleshooting on this front to try and fix this, but I don’t think we managed much better than this. But I’ll take that over nothing! :D

I’ve since removed the Dropbox share, but the final notebook can be viewed here.

After the session on Day 1, I cleaned up the working notebook. I didn’t add anything that wasn’t discussed in the session, but instead recorded more of my commentary in the notebook itself since there wasn’t time to record it live. The learners appreciated this the next morning, especially with the NBViewer updates, since they could refer back to what we had done in case their notebooks were missing things we would need that day.

I made a conscious effort on Day 2 to slooooow doooowwn, and I think I succeeded. We ended up making it to the goal, which is how to write Python scripts that behave like shell commands (showing that shell commands are not magic, and you, YES YOU!, can write your own!). The feedback was generally more positive on this day, and the discussions that followed indicate that people were happy with what they had spent the time learning.

Thomas closed out the day with a lesson on Git. Despite it being his first time teaching that particular lesson (it didn’t show!), he went at a good pace and we were able to get through pair-wise collaboration on a publicly hosted git repository (using GitHub). Among the teaching tools I plan to steal from him is his analogy of commits as group photos. That is, putting things in the staging area can be thought of as bringing people into the frame of the photo (and perhaps excluding others), while the commit is taking the photo itself and then clearing the frame.

It was great to meet and learn from the learners, helpers, and my fellow instructors. I got the full Oklahoma experience, too little sleep, and plenty of ideas for next time. Looking forward to many more!

Thanks especially to our host Dana Brunson for putting this together!

— david