Note: the title suggested itself when a melody from a certain song by the Roches popped into my head. That’s exactly the kind of thing that engineers might find puzzling or irrelevant, at least within an academic context, but it may tickle the funny bone of anyone who knows the Roches song I’m talking about.

A couple of weeks ago, Tom Woodward and I had the privilege and pleasure of presenting the new Academic Learning Transformation Laboratory, ALT Lab, to the VCU School of Engineering at their undergraduate studies retreat. We were on a high platform, and our good friends and colleagues from Engineering were arrayed below us at circular tables, waiting respectfully for the cookies that would follow our talk. (The cookies were on the schedule already; we didn’t bring them, though in retrospect we should have offered.)

We came to the task with a little trepidation. As one of my Virginia Tech colleagues once said, “Gardner, you have to understand: these folks really are rocket scientists.” Just what a Miltonist wants to hear, though perhaps Miltonists are the engineers of those who study literature (I did hear of a senior Miltonist shouting out the correct date when a grad student got it wrong at a conference, so obviously we don’t make it all up as we go along). My VT colleague did have a point, however: engineers are smart, math-savvy, and makers of high precision and (sometimes) no small degree of monetizability. Engineers have to get the answers as right as possible, lest the bridge fall down or the pacemaker short out. Precision is an ethical imperative of the discipline. Not much talk about epistemology within engineering circles. A realist epistemology underpins the discipline’s work. So here we were, a history major (Tom) and an English major (me), talking about concepts and pedagogy and doing our best to demonstrate some core questions about understanding and some pretty nifty examples of new ways to represent and do math. And of course I led with the patron saint of ALT Lab, an electrical engineer (with patents!) named Doug Engelbart, and I shared with them Engelbart’s abiding vision of human capability, as well as the conceptual framework that supported and represented that vision.

I also worked in two film clips from The Right Stuff. I was very excited to do so, as you can imagine.

Time flew by, we fielded some questions about learning and digital technologies, and then we packed up our sample cases, so to speak, and left the platform. I found, as always, that my trepidation had turned to excitement. Don’t let this get around, but engineers are some of the coolest folks on the planet, even though some of them pronounce “blogging” as if it rhymes with [redacted]. Not to worry: I’ve known a couple of champion engineer-bloggers in my day. I know it’s possible.

My one regret is that there wasn’t enough time to get to the last three slides in our deck. These were slides that I thought might stimulate some interesting conversation, if not controversy. They also represented a little conceptual framework I was eager to try out, to hear what they might say in response.

Here’s the first slide:

The idea here was to identify four stages of engineering process. No doubt Montessori or Papert covered a similar idea somewhere. Nevertheless, I wanted to try out the idea that both unstructured and ultra-focused stages informed the particular kind of making that characterizes engineering. As I put the slide together, I realized the stages probably informed many other disciplines as well–perhaps all of them.

Play is pretty obvious. Both Huizinga and Bateson have written eloquently about the way play pervades culture, as well as about the way in which play is liberatory in terms of thinking. Some kinds of play involve very elaborate if-this-then-that modes of thinking, all counterfactual, and all on the edge of a dreamworld where everything can turn to metaphor. Here new ideas first emerge. I thought the idea of “play” might be challenging within an engineering context, so I wanted to see what they’d say.

Tinkering is playing with what emerges from play. Tinkering is a more focused and experimental version of play. I’m particularly drawn to the idea of “stochastic tinkering” much loved by Nassim Nicholas Taleb. And here I thought I’d have a slam dunk with my colleagues, since many of the engineers I’ve talked to are quite comfortable with the idea of tinkering. Indeed, many of them became engineers precisely because they love to tinker. Our station engineer at WFDD-FM was nicknamed “Tink,” and it was always a treat to visit him in his office and see all the pieces and parts carefully hanging on the wall or gathered into small plastic drawers in apparently endless organizers.

Practice comes in from music, for me, but stands for the deliberate repetition of any task until one can do it without thinking. Many learning theorists (and others) call this quality “automaticity,” and while human beings are not automatons (at least, not yet), it is still very useful to be able to perform precise motions repeatedly, and to focus on getting it right, whatever “it” is.

Make is as obvious as play, though I figured it would be the most obviously resonant and relevant element for this audience.

Then the next two slides were to explore more complex and, I believe, more accurate representations of the linear process, which even in its more radical moments (“play”) still resembles a standard design model, what project managers would now call a “waterfall” model.

Iterating upward in complexity, I had this slide for us to consider:

Now the line has become a circle, with the implied argument that the cycle cannot be considered complete when the make occurs. Whether one calls this iterative development, rapid prototyping, or the like, the idea is that “make” is more or less perpetual beta. I don’t think we can say that a bridge or a jet engine is itself in perpetual beta, in terms of the engineering that keeps the bridge intact and the jet aloft, but of course we can always iterate toward better bridges, better engines. I am especially interested in the notion that one should play as the next step of iterative development, not simply refine or troubleshoot what’s been made. This is a challenging notion and I could be wrong, but it seems to me that one danger of a thoughtless. automatic model of iterative development is that one can be confined within confirmation biases, iterating away on the polishing of the thing that cannot be polished without revisiting the essential question of “what are we assuming?” (In the article I linked to above, the dangers of too much automaticity are illustrated beautifully by the ham-in-pan story.) I should also say that I am continually saddened by how much “educational technology” is pretty much ham-in-pan thinking. But I digress.

Finally, the most complex of the slides I’d prepared:

The implicit argument here has to do with resemblances and analogies. How are play and practice related–indeed, how might they be versions of each other? Similarly, in what way do making and tinkering represent similar activities?

I’ll leave those questions as exercises for the reader.

And yes, I confess: still loving the engineers.