Software Carpentry at Johns Hopkins

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: Below I have some notes on the sections I taught, plus some overall thoughts. Continue reading “Software Carpentry at Johns Hopkins”

Software Carpentry at Johns Hopkins

Teaching Python at Software Carpentry – Toronto, February 2012

Last week I had the privilege of teaching Python (and generally helping out) at a Software Carpentry bootcamp at the University of Toronto. Mike Fletcher and I worked together to make a lesson plan targeted at students completely new to Python. Overall it was a great experience and I had a lot of fun meeting some other Pythonistas. Here I’d like to talk about some lessons learned from our teaching. (Update: Mike has written up his thoughts as well.)

The overall narrative of our lessons was that they were trying to read a CSV data file. We built up the very basics (data types, if, for) up through functions and modules in a total time of about 5 hours. We tried to alternate between a few minutes of lecturing and a few minutes of exercises that students typed and ran on their own computers using template files we had given them. I think we built a good narrative and I particularly liked how we segued into writing functions, writing modules, and re-using code. However, for the time available and the students we had I think we could make improvements.

Our students were mostly science graduate students. They were largely not experienced programmers and none of them (as far as I know) had experience with Python. We had just a few hours with them, though they will be continuing with online lessons. Our particular failing in this situation was that the complexity of our exercises quickly outpaced the experience of our students, making them confused and slowing everything down. When I do this again I will probably iterate on the same content but update the exercise templates to be much more filled in, requiring the students to fill in only a couple of key lines. This will hopefully allow us to move through more content in less time without sacrificing much in terms of what the students practice.

Teaching in such a short amount of time is a challenge. How much time do you spend selling Python, all the great modules in the standard library, and the great third-party packages that make Python an excellent choice for scientific computing? If you do some really compelling demos maybe the students will be more inspired to continue using Python on their own and it won’t matter that you’ve sacrificed time you could have spent teaching them the basics. How much time do you spend teaching them about installing and managing Python and third-party packages? It’s hard to make a case that you should teach this at all in the first class but it’s bound to come up for everyone when they stumble across cool-package-X.

I definitely feel some initial demos are in order, just enough to say, “Look, you can do all this great stuff with Python!” Then you’ve got to start teaching something and keep it moving as you do.

The Udacity Teaching Model

I’m currently taking CS373 at Udacity (they also offer CS101). They have a pretty cool teaching model with a few minutes of instruction followed by short quizzes so that you get immediate feedback on how you’re doing. The quizzes even involve programming: you’re given a nice text editor (implemented in JavaScript, I believe) that does nice syntax highlighting and automatic indenting. It’s usually pre-populated with some starting code and test variables. You write your code and click “Run” to see the output. When it’s satisfactory you click “Submit” to have your output scored against what is expected. If you like you can write your code in your own editor/environment and copy it back when you’re ready to submit.

The Udacity classes are not live but I can imagine a similar tool being useful in a live classroom setting because it gives the teacher the chance to see what students are writing and what output they’re getting. The code is run on the server side so it can be consistent for everyone. And though it’s not an ideal development environment, it does help for students who might not have Python installed on their computers. One drawback is that I don’t know how it would work when it comes to teaching students to read and write files.

Teaching Python at Software Carpentry – Toronto, February 2012