What Deep Thoughts Look Like
Before writing yesterday’s post about assessment, I should have explained what I mean by”fundamental concepts”. I’ll start with Lewis Epstein’s wonderful book Thinking Physics:
Here’s a typical problem from the book. Put a block of ice in a bathtub, then fill the bathtub to the brim with water, so that the block is floating freely. When the ice melts, will the water level go up (causing a spill), go down, or stay the same? Hm… well, the ice displaces its own weight of water, so when it melts, it exactly fills the “hole” it made, so the water level stays the same.
Now let’s try something a bit more complicated. Put the same block of ice in the bathtub, but put an iron weight on top of it, and then fill the tub to the brim. Now what happens when the ice melts? Does the water level go up, go down, or stay the same? Epstein would say that if you can answer questions like that, then you can think physically. It isn’t about calculation—as with Dan Meyer’s “Joulies“, it’s about understanding principles and following them through to conclusions.
The real aim of Software Carpentry is to teach scientists to think like that about computing. We want people to understand the principles:
- model-view separation
- human-readable vs. machine-readable data
- copying vs. aliasing
- state machines
- different models of computation (imperative, functional, reactive, declarative)
- interface vs. implementation
- the complementarity of algorithms and data structures
- code as data (and data as code)
The Unix shell, Python, SQL, regular expressions, and what not are how we hook people (“Hey look, something useful”) and how we get these principles across (as with most big ideas, any direct description is either incomprehensible or banal). However, these principles aren’t natural laws in the way as F=ma and the Second Law of Thermodynamics—if you compare them to the principles I listed a month ago, there’s overlap, but the lists aren’t the same. So:
- What is the best way (or a good, stable way) to carve up this intellectual space?
- How do we tell what a particular person actually understands?
“Write this program” is not an answer to the second problem—as many studies have shown, people can solve routine problems by rote without really understanding what they’re doing. (This is the starting point for Eric Mazur’s work on peer instruction, and the reason so many of us are so skeptical about things like the Khan Academy.)
Can we just teach the tools (for some value of “just”) and let the big ideas sort themselves out? The answer is clearly “yes”, because that’s what I did from 1998 to 2007. Does it work? I think the answer is “only partially”: some people generalize from specifics to principles correctly on their own, but many either don’t do it at all, do it incompletely, or do it incorrectly. And does it matter? I think so: I think that if we want scientists (or anyone else) to use computing on their own, for their own ends, they need to be able to step past what we’ve shown them with good odds of success, and that certainly requires understanding “why” as well as “what”.
Very thought provoking. Here are a few such thoughts.
You’re up against a cultural phenomenon here. Howard Gardner documents, in “The Unschooled Mind”, how hard it is to dislodge ways of thinking established in childhood and how badly secondary and post-secondary education fails on this score in all fields. Schools focus on providing concepts to think about (in the same old ways) rather than getting students to examine the concepts with which they think.
You can’t “just teach the tools” and be successful. You have to focus on how to think and how to learn as a lifelong process. You do this when you teach keywords in SVN and then explain about provenance and tell scary stories about what happens when it’s lacking. You do this when you talk about experiments proving that programming measurably improves when testing comes before coding rather than after. The whole software carpentry course needs to be permeated with that, with “the why”.
Teaching software carpentry might benefit from having a “where do you go from here” section at the end of each discussion of a particular tool. You can’t teach everything, even if you had more time, so you need to equip them with the learning tools they’ll need as they go on. I think one of the most valuable things you did at the most recent boot camp was actually look at the library reference for PIL and demonstrate how you go about running little experiments with it to get to know it. The table of contents for the Python documentation says “Library Reference: keep this under your pillow”. I think of Google as one of my most important programming tools. If I’m baffled by an error message I Google it.
You might consider the peer learning or pair programming experience in the classroom. Find the more experienced students in the classroom and pair them with the less experienced. Have the less experienced of the pair do the programming (at one laptop) with the more experienced looking over their shoulder. That might help the bored and the lost 2/3rds of the class get more out of it.
Another skill that might be worth adding to the course is code reading and code review. It might help introduce students to more realistic code examples without taking the time needed to have them do an exercise on the scale of a small project.