Amsterdam Bootcamp

This post originally appeared on the Software Carpentry website.

What started out as an unexpected proposal from Greg became very much alive on May 2nd, as 40 physicists poured into the classroom at VU University Amsterdam and started up their laptops. After introducing the teachers (Stefano Cozzini and Justin Ely) and the helpers, we were off: the very first Software Carpentry bootcamp in the Netherlands!

In the months leading up to the bootcamp, I had been surprised at the sense of timeliness the bootcamp generated. People here clearly see the need for computational training, most importantly young scientists themselves—available tickets were mostly gone within a week.

The program of the workshop had been announced as being geared towards teaching you "how to build better code in less time". It included the usual Software Carpentry topics: the UNIX shell, Python programming, version control (Subversion, by popular request), and some data management and matplotlib.

During the two days of the bootcamp, Justin and Stefano did a great job at teaching these topics, mixing interactive sessions with some more theoretical material on software lifecycles. Especially the session on Subversion was a big hit: people made over 80 commits to our shared repository within an hour, and seemed to grasp the material well. (Today, an attendee told me he's actually using it for his work now).

Some other things that worked well included:

  • The little trick with green/red sticky notes to signal helpers;
  • Frequent, short breaks;
  • The VirtualBox VM: this pre-empted a lot of setup issues (we encountered very few of those).

And yet, I'm not sure the bootcamp was a definite success overall. Looking back, and reading the feedback, we hit two snags.

The first will be familiar to Software Carpentry regulars: we had a large, inhomogeneous group. This made it very hard to teach everyone something new, while at the same time not losing anyone. Especially while teaching Python, we stuck too much to tutorial-level topics. This didn't leave enough time for more advanced topics such as program structuring, debugging, or object-oriented programming.

Secondly, and more importantly, I'm not sure we kept our promise of teaching "how to build better code in less time". Sure, judging from the feedback, some people clearly got useful skills out of the workshop. But quotes like this one…

The bootcamp was advertised as saving time writing code. I really wanted to learn that, and I don't think I did see anything saving time.

…and this one…

I went looking for strategy in software building, learning how to make a plan and follow it together with other people. Sadly the course stayed in a much more introductory stage to particular tools.

…show that this was not enough.

Could we have done better? I think we could have, if we'd put more effort into teaching materials in a useful context. This was one of the reasons why the version control topic was a success: people went through real-life scenarios, got their hands dirty, and learnt something useful that way. Doing something similar for Python programming—letting people work on a real program, while learning about structure, documentation, refactoring, etc.—would have made a difference. Many attendees are longing for such realistic examples.

And, of course, if you're organizing a bootcamp: think twice about the type of audience you're inviting. A generic mix of everything from novice to expert will make teaching the bootcamp more difficult. That's certainly something I'm going to keep in mind for next time.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github