Reading about cognitive apprenticeships brings up all sorts of fun moments. For instance, the ideal way to design an apprenticeship experience is to have students do global tasks early on, then local tasks later. Do something that lets them see the big picture (assemble a whole dress) first before focusing on detailed parts (cut out a piece for a dress).
(Explaining the global-to-local progression of tasks given to tailor's apprentices) "Reversing production steps has the effect of focusing the apprentices' attention first on the broad outlines of garment construction as they handle garments while attaching buttons and hemming cuffs. Next, sewing turns their attention to the logic (order, orientation) by which different pieces are sewn together, which in turn explains why they are cut out as they are. Each step offers the unstated opportunity to consider how the previous step contributes to the present one. In addition, this ordering minimizes experiences of failure and especially of serious failure." --Situated Learning: Legitimate Peripheral Participation by Lave and Wenger, p. 72
And I think: huh, that has some implications for computing education.
- high level languages (python) first, instead of low-level (assembly, C)
- teach release engineering first, instead of programming
- wow, all sorts of stuff seems backwards now.
Sebastian and I make an interesting comparison of case studies. We're both largely informally taught in software engineering (we've had a couple classes by now, but still -- I'd say the bulk of our knowledge comes from outside-school) but had opposite sorts of informal educations in software engineering.
When I was 15, I started by learning C/C++ programming; I started small and low-level, and gradually climbed bigger and bigger and higher and higher in abstraction. I've never quite gotten the hang of putting together large and complex software projects; I still think in tiny pieces of code. I struggle to see outside the little box I first learned in. Then again, I didn't realize I would go down the route of "software" as a field when I was younger -- computers were a fun thing to play with, but I thought I was going to be an art major.
In contrast, when Sebastian was 15, he started as a release engineer, putting together Linux distributions; if that's not a giant, complex, and high level project, I don't know what is. When we first met, I could code circles around him. I think I might still be able to today, but the gap is definitely closing -- in any case, he started high-level and with a global scope, then worked his way down through Python, into C, into embedded developent with microprocessors, and... seems totally fine. If you compare our 18-year-old selves in terms of "ready to be hired as a full-time software engineer without going through college," he wins hands-down.
Looking back on this, I think I'd have liked to learn software engineering release-engineering-first, but that's not an activity I would have recognized as "software engineering" when I started ("it's not writing code! but software engineering is all about writing new code!") -- which goes to show you how much about software engineering I actually knew in high school.