Second Round at Lawrence Berkeley

This post originally appeared on the Software Carpentry website.

Last week we finished up our second workshop at Lawrence Berkeley Lab. This time around, we tried a more free-form version of the feedback exercise in which students live-typed their feedback into an Etherpad at the end of each day. This went very well, as it gave us time to gather unique comments, get a rough idea of the amount of support for each comment, and to respond to some of the comments in real time. We asked three questions: what was good, what was bad/confusing, and what we didn't do or talk about that we should have.

The Good

• Introduction to python and how to install things with command lines
• Understanding python objects, classes, functions, methods, etc.
• Thinking about how to structure the directories for a project
• Hearing how regular Python users use Python (+1)
• Just getting finally to write some .py code!
• Real world example-driven exercises
• Knowledge of helpful data types in Python
• iPython notebook and Etherpad are amazing (+1)
• The party on the Etherpad !!!!! (+1 +1) [Ed: the students had some fun "passing notes" in the Etherpad]
• Patient, fast, specific help (+1)
• An explanation of git from people who use git (+1 +1 +1)
• Inside structure of git
• You put a lot of things in my brain in a very short time (+1)
• Standalone scripts is my new goal for my code!
• Start thinking about how to test code for reusability
• Danish and coffee / snacks / food juice

The Bad or Confusing

• Python version issues, especially multiple Python versions on same system (+1 +1 +1)
• Relationship between Anaconda/IPython/Enthought/system Python
• Use of iPython Notebook vs console, roles in real-world code development (+1)
• Glossary/handout on Python would have been helpful for beginners
• Most of the Unix tutorial was extremely basic (+1 +1 +1) [Ed: There were two follow ups to this comment in which students said they needed the basic tutorial badly.]
• Worrying about whether to abandon perl and R for python - then I'd have to start the learning curve all over.
• Too fast for beginners, but noticed that others were bored (+1)
• Not enough 'signposting' during talks/lessons
• It's over now :\

Things We Didn't Do or Talk About But Should Have

• Online "getting started with Unix" tutorial before class (+1 +1 +1)
• Making and annotating/labelling plots, more Matplotlib (+1 +1)
• Discussion of computational and memory efficiency
• "Best practices" for developing and maintaining code (+1 +1 +1 +1)
• Fitting data (+1 +1)
• How to share code, etc. with those who don't use version control
• Working with specific types of data (ie, DNA)
• More about modules and importing, common bugs, etc.
• Is there a better way to find help than google and stackoverflow?
• Overhead when working with extremeley large data sets

Thanks to Shreyas Cholia and to instructors Matthew Brett, Cindee Madison, and Ariel Rokem and helpers Paul Ivanov and Matt Terry.