This week Joshua Smith and I hosted a Software Carpentry boot camp at Johns Hopkins University in Baltimore. We also had awesome teaching help from Sasha Wood and Mike Droettboom.

We opted for a small class since this was our first time hosting a boot camp and because of space limitations. Based on the rate at which people signed up for the class it didn’t seem like there was massive local demand anyway, but we were pleasantly surprised when we had a student from Brooklyn, NY and a student commuting from Virginia. There is definitely some existing demand for the skills Software Carpentry offers and I’m glad we could put on an accessible boot camp for those people.  Most of the rest of the students were physics and astronomy grad students or post-docs from JHU and STScI.

The boot camp was broken into four half-day courses: shell, Python, version control, and software engineering. Mike and I co-taught the Python and software engineering sessions.

The overall feedback from the students was quite positive and I’m looking forward to doing this again. (Here is the requisite good/bad Software Carpentry feedback post: http://software-carpentry.org/2012/06/feedback-from-johns-hopkins/.) Below I have some notes on the sections I taught, plus some overall thoughts.

Python

We taught the Python programming session entirely within the IPython notebook. The notebook is this perfect mix of editor and Python interpreter. It allows the students to experiment and quickly iterate as they test and write code. They can write small or large blocks of code, playing with one line statements or multi-line functions with the same ease. There is no switching between editors and terminal, which I think makes for just one less thing to interrupt the students’ thoughts.

The notebook is also a great way to sell Python. It shows off the value of Python’s docstrings; and IPython’s tab completion, shell integration, Markdown cells (with LaTex!), and inline plots all impress people.

And it’s not just a great teaching tool. I use the notebook almost every day at work as a Python developer.

Software Engineering

In this session we continued to use Python but focused on teaching documentation, testing, debugging, and the practice of building a library of trusted tools. We discussed general practices but also some Python specific tools like nose and pdb.

Here we continued to use the IPython notebook to demo certain things but we switched to a more traditional editor + terminal workflow to demonstrate making a Python module and script, plus accompanying tests.

This software practices session took the place of the SQL or image processing lessons that have commonly occurred in the second-day time slot at Software Carpentry boot camps. We opted for this because we think it makes learning the material easier. Learning to program in Python and soak up a bunch of software engineering practices is a lot to ask of people who may not program much in the first place.

I think splitting the material like this paid off in terms of student uptake of the material. Software Carpentry is all about teaching good software practices so anything that improves that is good. And Python is also one of the big draws of the boot camps (at least this one), so having people spend more time doing practical work in Python is valuable to them.

Other Notes

I think we came up with a good curriculum that I’d use again. All of our material is on GitHub, though there aren’t detailed instructions for every section.

A couple problems we ran into:

• We distributed a Linux VM pre-loaded with all the software people would need, but a few people had a hard time running it either because they had older computers or corporately managed laptops that would not let the VM run.
• The local network blocked some git protocols. We found ways around the problem but it never helps to have these hiccups when introducing new technology.
• I got the feeling people weren’t asking for as much help as they should have been.

Things I want to do in the next boot camp:

• Use the sticky notes others have been using for students to signal they need help or have finished an exercise.
• Spend more time discussing data provenance.