As our next Software Carpentry boot camp 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 boot camp 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 boot camp 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 boot camp, 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 boot camp 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 boot camp, 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 boot camp 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!
Originally posted 2013-04-03 by Paul Wilson in Content, University of Wisconsin - Madison.comments powered by Disqus