Research-Based Course Design

This post originally appeared on the Software Carpentry website.

I've written before about the breadth and depth of Juha Sorva's work on computing education. His latest contribution is a paper co-authored with Otto Seppälä titled "Research-Based Design of the First Weeks of CS1". In it, they tie the specifics of the new intro programming class at Aalto University directly back to CS education research. More specifically (from their abstract):

On the basis of cognitive load theory, theoretical models of instructional design, and empirical findings from computing education research, we propose three independent but compatible and complementary frameworks that can be used in introductory programming education. Motivate-isolate-practice-integrate is a framework that marries project-driven learning to careful management of cognitive load through the selection of learning activities and the isolation of partial tasks. Head Straight for Objects is an outline of an introduction to programming that emphasizes object-orientation early while mediating the cognitive load intrinsic to object-oriented concepts. Finally, the principle of explicit program dynamics states that the runtime dynamics of programs should be a continuous and explicit theme in introductory programming education. We illustrate the application of the three frameworks in the context of a university course.

There are good ideas on every page, though it will be hard to incorporate many of them into Software Carpentry: Aalto uses several full-length courses to introduce students to programming, where we have (at most) one day. My biggest take-away from this paper, though, is the fluency with which the authors connect current research (science) to their instructional design (engineering).

This paper also prompted a question that I probably should have asked years ago. For years, CS educators have argued over objects first vs. objects later, i.e., over whether someone's first encounter with programming should be with objects, or whether they should start with procedural programming and be introduced to objects later. Proponents of the first argue that objects are both natural ("the world is made up of objects") and authentic ("real programmers build real programs using objects"); advocates of the second point out that "...writing even the smallest meaningful class requires approximately 15 basic concepts: object, class, instantiation, constructor, method declaration, formal parameter, return type, variable, type of variable, value, integer, assignment, method invocation, actual parameter, returning a value" (from Michael Caspersen's thesis, quoted in Sorva & Seppälä).

If the audience is scientific programmers, are arrays (or data frames) the equivalent of objects? I've written lessons both ways, i.e., introduced arrays early (like our current Python lesson) or deferred them until learners had seen lists, loops, and functions (our older material). I don't have any strong evidence that one is better than another, either pedagogically or motivationally, but (a) at least I've realized that I should be asking, and (b) the work of Sorva and others gives me a framework for thinking about answers.