From a Helper to an Instructor

This post originally appeared on the Software Carpentry website.

This blog post is actually a bit overdue as the first time I instructed at a Software Carpentry bootcamp was over a month ago in Manchester. However, as now I had an opportunity to teach twice (recently in Krakow), this gives me more credit to share my experience of taking a step up from being a helper to being an instructor.

I had helped at bootcamps in the UK so I knew how the materials were taught and what they covered. Nevertheless, it still took me a lot of time to go through the modules I was supposed to teach making sure that I could seamlessly not only follow all topics, examples, and exercises but also present them in a clear manner. As a helper most of what I had to do was to solve ad-hoc problems reported by the bootcamps attendees. As an instructor I had to make sure that everything I was saying was consistent with what I said before and logically led to the next step.

I also learnt first hand that addressing a diversified audience is always challenging. In both Manchester and Krakow I experienced the difficulties of teaching a group who (according to the pre-questionnaire) varied from those who, for example, had never used Python at all to those who "strongly agreed" that they can write a Python program. This meant that I was going to either lose half of the group or make the other half terribly bored. I thought that the former was worse. Software Carpentry is supposed to be improving researchers' computing skills and not discouraging them even more from the world of programming, testing, and using version control. I figured that those who were already quite familiar with the material would catch up with their Facebook in the worst case, and refresh their memory and maybe learn a few details they didn't know in the best case. Pitching at the right level is difficult.

About a year ago I witnessed a situation (not at a SWC bootcamp) when an experienced developer was trying to explain to a complete novice the mysteries of Git. To cut a long story short, it didn't go well—at the end the novice was still clueless, but what's worse, the developer also seamed somewhat lost in his explanations. As I was supposed to teach Git, this memory became quite fresh in my mind. Fortunately, I was able to observe as a helper how Mike Jackson taught Git at previous Software Carpentry bootcamps and I knew that teaching distributed version control can be done effectively without confusing the students and yourself. I used practically the same materials which Mike presented introducing only small tweaks and followed Mike's teaching approach.

On more practical note, I learnt it the hard way that teaching a two-hour block standing rather than sitting affects my typing skills pretty badly. After about 15 minutes my back and wrists were aching, I had to look at my laptop monitor from a very weird angle and the number of typos which I made was growing exponentially. It all could have been avoided if I got myself a chair to sit on.

Instructing at Software Carpentry bootcamps is probably a different experience for everyone. Although, as I had a chance to talk to two other people who recently taught for the first time, there was one thing which we agreed on: allocate sufficient time to prepare for the bootcamp. Don't assume that it'll be enough just to flick through the materials and copy them over to your bootcamp branch. If you are an experienced instructor, this may work. But if you've only been a helper until now, you'll need to put more effort. But the payoff when you see the learners going "Ah, now I get it", is well worth it.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github