Feedback from Workshop at UFSC

This post originally appeared on the Software Carpentry website.

Last December we ran another R-based SWC workshop at University of Santa Catarina (Florianòpolis, SC, Brazil). The primary target audience encompassed grad students from the Biology Faculty who had some experience in programming and R. Raniere Silva (an undergrad in Applied Maths at UNICAMP, Campinas, SP, Brazil) co-taught the workshop with me and the Ecology grad students Renato Morais Araùjo and Juliano Bogoni (Department of Ecology and Zoology) acted as our hosts and in situ organizers.

As a Brazilian who had never taught a SWC workshop in Portuguese, this was definitely an interesting teaching experience. In some ways it was very nice to teach it in Portuguese, but in many instances I had no clue how to translate some of the jargon from English - big thanks to Raniere for helping me out with this!

Things progressed somehow slowly, as, for the first time (at least to me), we had no helpers available. Yet, we managed to cover the entire program, which included:

Day 1: Basics of R programming, including data types, subsetting and vectorized operations; functions in R; How to structure and organize projects; control flow (if/else, for and while loops, apply family in R, and the package plyr).

Day 2: Unit testing; The Unix Shell; version control in git; exercises on GitHub; reproducibility, including an example with the package knitr.

Everything in R was taught using RStudio, while Terminal (or GitBash) was used to cover the Unix Shell and git. Most of version control was primarily covered on the command line, though few examples of the add-and-commit cycle were also covered in RStudio.

Most of the experiences and workflow have already been covered on a previous post, therefore I will focus on the novelties.

Because in Brazil students from Federal Universities do not pay for their studies (for those who do not know of this, public institutions in Brazil provide studies 100% free of charge, all based on tax-payers money), we made an agreement with them: they would pay R$50.00 upon registration to secure a spot and we would return their money back on the first day. We had initially 26 students, of which 17 (5 women, 12 men) remained until the end. Some of the students were total beginners (even though the registration page was really clear about the expected advanced expertise level), and dropped out after the first day.

Raniere and I took in consideration feedback from previous workshops and included more exercises for students as things went on. To me it is still hard to decide how many exercises and how much time to each one, as things can escalate very quickly, and sometimes delay the schedule (for a good reason though). Apart from making them think of the content, I realized it provides a quick opportunity to catch up on topics they missed or were not really comfortable with. I will definitely pay more attention to this matter on future workshops.

For the first time, I tried to introduce the concept of testing departing from a test-driven development approach. To be honest, it was one of the best experiences I had so far covering this topic, as it really made students think about what it was they wanted to achieve with writing functions. I used some very simple examples where given a 0 or NA as inputs, the expected outcome was actually not what one would naturally expect (e.g. an error). I first made them come up with a function plan: conceive the function mentally, write at least 5 tests covering the desired output, obvious functionality and corner cases, and then write the function. Some students succeeded really well, while others fell behind - as with most topics considering that programming experiences were very mixed within the students.

Motivating students to learn the Unix Shell is a big challenge because, unlike our R lessons where interesting things/examples are intermixed with overall content, nice/handy day-to-day examples are generally exposed towards the end of the lesson (at least in our previous experiences). To address this issue, we changed the original SWC lesson a little. Instead of adopting the Nelle's story as a starting point, we used a messy repository and had students change it to follow the project structure that we presented on the first day. Students had fun doing it and were impressed how some tasks, e.g. moving the files

graphic-[0-9][0-9]-final-version.jpg

to the directory

img

and remove the

-final-version

from the filename, are easy from the Terminal.

I've talked about this in my previous post, but I think that next time I'll make an effort to teach a 3-day workshop instead of 2. In my opinion, 2 days may be enough only to expose students to the different concepts and topics. However, if we really want to get them more excited and on board with the content, we need a bit more in-depth material, as the ones I've trying to cover in 2 days. That was the negative feedback we got from most students: things were going too fast; too much to be covered in 2 days. They got excited with reproducibility and knitr, but unfortunately we could only show quick examples on how it all works. This could be easily expanded on a 3-day scenario - and, in my opinion, of great advantage to the average life scientist.