Acccording to Wikipedia, the terms "programming in the large" and "programming in the small" were coined by Frank DeRemer and Hans Kron in 1975 to describe two very different approaches to creating software. Programming in the small is where everyone starts and most people remain: with code that is small enough for one person to understand. By contrast, programming in the large describes the construction of systems that need to be engineered as collections of subsystems.
I wonder if it's possible to make a similar distinction between teaching in the small and teaching in the large. I don't mean "teaching a few students" and "teaching many students", but rather "building small lessons that only you and a few other people will deliver" versus "working with many people to build large, complicated lessons". Given this, even people who are in charge of twenty sections of Psych 101 at big state schools or running MOOCS with tens of thousands of participants are teaching in the small, because they don't work together in dozens or hundreds to co-create and share material.
This analogy is flawed, but it's giving me a new way to think about what I've learned about teaching over the past five and a half years. For example, it's tempting to say that programming in the small is a craft, where programming in the large is engineering. In my experience, though, that distinction is inaccurate because it doesn't take cognitive hysteresis into account. Many good programmers have gone through three phases:
They learn craft practices by building small programs on their own or in school.
They learn engineering practices by helping to build larger programs in work terms or jobs.
They then apply some of those engineering practices to small-scale jobs because they work better than the craft practices they supplant.
For example, I use version control and repeatable testing on small projects, but that's because I learned them on large ones and then scaled them down. Some other programmers go straight from stage 1 to stage 3 because they're lucky enough to work with people who've gone 1-2-3, and so can pick up engineering skills while still on small projects. In contrast, I suspect most teachers are stuck in stage 1: there aren't big collaborative projects where they can learn the equivalent of engineering for lesson development, which means nobody is scaling those practices down to enable a direct 1-to-3 transition.
I know I'm not objective, but Software Carpentry's collaborative lesson development process feels like it might be a step toward teaching in the large. Dozens of people can and do make lots of incremental contributions to its lessons, while more than fifty have now told us what they actually do when they teach those lessons. It feels qualitatively different from what I've done before, and what I'd like to do next is scale it up tenfold to see what other new practices emerge.comments powered by Disqus