Teaching basic lab skills
for research computing

Connecting Bootcamp Content to Motivation and Best Practices

As our next Software Carpentry bootcamp quickly approaches, we have been struggling with many of the usual questions of what to teach and what not to teach. We expect a broad array of skills and experience (pre-assessment is yet to be completed), and want to make sure that all the learners leave with a clear motivation to build on what they learn.

As we perused other bootcamp agendas and curricula, we were concerned about so much focus on programming and Python in particular. In particular, there has been much discussion about what the real goal of this part of a Software Carpentry bootcamp is and should be. There is not enough time to teach true novices how to program, it is presumptuous to assume that people are coming to learn Python—it's not a Python bootcamp, after all—and we are drawing from a broad cross-section of people across a large research campus. But there must be a reason that every bootcamp dips its toe into teaching programming.

Then it occurred to me that we have already spent a lot of effort to refine the motivation and connect the practices and the goals—it's all in the Best Practices paper. There is even more there than we can do in a single bootcamp, but upon reflection it provides a clear narrative connecting the "why" and the "how".

Even better, it provides some catchier and slightly enigmatic titles for the different sections of the bootcamp curriculum. I was concerned that a dry list of topics such as "Python variables", "Python data structures", "Python flow control", and "Python functions" would turn some people away, as it looks too much like just-another-programming class. Instead, invoking the language from the paper, we can cover topics like "Write Code for People" in which we discuss variables and data structures, but without forgetting our motivation for choosing good variable names and convenient data structures. Or we can have "Don't Repeat Yourself", in which we introduce the ideas of modularizing your own code by refactoring into frequently used functions, and seeking third-party modules that do what you want. Our instruction of testing will be covered in a learning module called "Plan for Mistakes".

Our instructors are now challenged to make their material evoke these themes as students work through the exercises, focusing not just on how to write a simple function in Python, but why to do it and how to do it in a way that meets this motivation head on.

We'll report back in a month to tell you how it went!


Dialogue & Discussion

You can review our commenting policy here.