Teaching Software Carpentry workshops – some tricks of the trade

These days I am gearing up to teach two more Software Carpentry workshops, one in Wageningen, Netherlands, and one in Oslo, Norway. In the Netherlands workshop I will be teaching a module that I haven’t even looked at before. This led me to think about the things I do to prepare for a workshop. So, here is a list (in no particular order) of things that I do that others might find useful.

  • Go through the instructor checklist. Have a look at the other checklists too, that helps with figuring out what you can expect of the other parties involved in the workshop.
  • Recently, all of the workshop modules have been put into their own github repos. Go sign up for notifications for those that you are teaching. It is highly likely that discussions about the material will prove useful. These can contain both information about technical issues and about how to teach that particular module.
  • Go through your module(s) on as many platforms that are available to you. If you are thusly inclined, consider creating a virtual machine or two and go through both the installation procedure and the module there. Remember, this takes time, so start before you think you have to, there will always be weird hickups.
  • Print out a copy of the lessons on paper and make notes on them as you go along. Take them with you to the workshop. During my first workshop I did not have a printout, and it was not a pleasant experience trying to switch back and forth between windows. I don’t know if I or the students ended up being the more confused.
  • Have a look at the wiki for technical issues and familiarize yourself with the latest technical annoyances.  Ensure that you have an easy way to get back to it again during the workshop. I have forgotten where it is a couple of times, and it was equally annoying each time having to spend time figuring out where it was.
  • Make sure that the host supplies stickies, and consider taking a backup stash with you in case the host misplaces them or simply did not get them because they didn’t believe in them. Ensure that you have at least twice as many stickies as students, sometimes they lose them, sometimes they spill coffee on them, sometimes they distractedly end up tearing them into tiny tiny little pieces. You get the picture.
  • During the workshop – USE THE STICKIES! They are a lifesaver. If you have not taught with them before, just give them one single go and that should be enough to convince you. It is a lot easier to keep track of where people are with them than without, you can keep a higher speed through the material without loosing anybody, and it is a lot easier to see who needs help. It also saves students sore shoulders since they don’t have to keep their hands up in the air until they fall off. On a more serious note, I suspect students ask for help more quickly with stickies since the overhead cost associated with it is reduced – it is not very taxing to put a stickie on your screen.
  • When you are live coding (typing on your computer) for the entire lesson it is tempting to sit down. Consider teaching standing up instead. It helps with speaking clearly and loudly enough so that people can hear. I also suspect that instructors may be quicker to go and help people when teaching standing up, because you don’t actually have to get up first. If you decide to teach standing up, tell the organizer so that they can fix something to have the computer on.
  • Bring good walking shoes. If you enjoy wearing heels, leave them at home. You are likely to do a lot of standing up and walking about, both during the workshop and in the evenings. You do not want to end up teaching with blisters. Also, you are likely to be walking around in a room with a lot of extension cords and leads lying on the floor. The risk of tripping over something is already higher than normal.
  • Bring throat lozenges or cough drops or whatever they are called, and a bottle of water. You will end up speaking a lot more than you are used to, which might lead to a sore throat, coughing and in a worst case scenario, losing your voice. I once got a coughing fit while teaching and it was not a fun experience.
  • If you can, try to get together with the helpers, the other instructors and the organizers the evening before the workshop. It really helps to have met before the workshop. Everybody, especially the helpers, are bound to have questions about things, questions that won’t have occurred to them until they are actually talking with others involved in the workshop. This is also good for giving last minute information, ensuring that everybody knows where and when to show up, organizing transport etc.
  • Ensure that you get to the workshop in plenty of time in the morning. The building you are teaching in might be confusing to navigate, so give yourself enough time to get there. You will then also have time to set up your own computer, sort out your papers etc.
  • Last but not least: have fun!

So there you have it!

The one where I went to Sweden

I spent some days two weeks ago in Stockholm, Sweden. Lex Nederbragt and I were invited by SciLifeLab to teach a Software Carpentry workshop there. This coincided with the very first PyCon Sweden Conference, and as the organizers would have it, I got to present a talk.

The workshop

The workshop went very well. Lex and I taught the by-now fairly well known novice workshop (if you want one at your institution, let them know!). Oxana Sachenkova, the local organizer, had also set up an intermediate workshop. The teachers in that one were Konrad Hinsen and Nelle Varoquaux, both flying in from Paris. Their workshop focused more on object oriented programming and intermediate git use. It was great meeting them, the only sad thing is that I could not sit in on their workshop

The division of labor between Lex and I have until now been that he teaches shell and unit testing, while I teach git and python. This time I taught both these parts from the new lesson material that has been developed. I had taught the git lesson earlier once before, so that material was well known to me. I think this lesson is reasonably easy to teach, the real challenge is to convey to the students why version control is useful at all. At this stage I am leaning towards most people not really understanding the need for version control before they have either messed up their work pretty badly, or have become involved in a joint development project.

I had not taught the python lessons before. These now take place entirely in the iPython Notebook. The first time I went through them, I actually wondered if I should return to the old lesson material, if nothing else because on the printout I had somewhere around 50 pages to go through. On the second run through, however, I realized that the notebook is a game changer. With the notebook, I could have the students editing and copy-paste code from earlier in the lesson, which would reduce the typing time and hence the teaching time dramatically. There were still things that I cut from this lesson – I did for example not go through he python call stack, simply because I still think this is too complicated for novices. Instead, I teach them the basic tenant “What happens in a function, stays in a function”, and that does seem to stick.

The conference and my talk

Due to teaching I only got to attend the last day of the conference. The programme looked really nice, and I got to see some really great talks. The morning of the last day opened with Laurens Van Houtven speaking about cryptography, and Jackie Kazil speaking about how she started using programming in her journalism and how that lead her to new pastures. After lunch there were several other talks, most of which were pretty technical. Such talks can be really good, but to me they lose their value when they don’t even have a 3 minute “subject of my talk for dummies” intro. 

My talk was at the end of the day, and was entitled “Python and Biology: a shotgun wedding” (pardon the pun, when the title appeared in my head, resistance was futile). The background for the talk was that I have several times during the last couple of years helped people – primarily biologists – start programming. Naturally, as opinionated as I am, I have ended up with some do’s and don’ts on where to start. I also included a bit of background on why life scientists have had to get into this game, and also showed some examples. I have included the slides below.

[gview file=”https://blog.karinlag.no/wp-content/uploads/2014/06/pyconse_blog.pptx”]

The talk seemed to be fairly well received – it was however aimed at novices, and there did not seem to be too many of those in attendance. I did however see some people nodding vigorously in the front, and got some really nice questions at the end, so all in all I think it went over well.