Changing Minds
I recently finished reading Andrea diSessa’s Changing Minds: Computers, Learning, and Literacy. My work on Madeup had me reading many books that mentioned this book, and I spent a good deal of time in diSessa’s earlier Turtle Geometry. So, it was only a matter of time before I read Changing Minds. In it, physicist diSessa discusses his work on developing a computational learning platform named Boxer, and as someone who’s trying to build his own such platform, I find myself thankful for him helping me steel my nerves against the rejections and skepticism I am bound to encounter.
My reading of the book is worth more if I publicly reflect on it, so I offer below some of the ideas that pinged around my head as I read Changing Minds.
Tools vs. Problems
The author notes that we educators assign problems that require students to exercise a particular tool or strategy we want the students to learn. But tools and strategies are devised in order to solve problems and are therefore secondary to the problems themselves. By assigning artificially contrived exercises, we reverse the order of importance. We make the problems secondary and tools primary. The terrible consequence of this reversal is that students do not learn to apply the tools and strategies since they’re used to having us pre-equip them before they encounter a problem.
When I think about how we might make problems primary, my mind quickly gravitates toward work. Work is where problems are king, right? Clients present their problems but don’t specify how the workers are to solve them. That’s the authentic learning experience we want to emulate in schools!
However, a talk I attended a few days back reminded me that problems are not actually primary in our workplaces. I mentioned to a fellow from industry that we were using Haskell in my programming languages class, and he suggested I use a tool that “might actually help students get jobs.” He was as caught up in the tool craze as we teachers.
But tools aren’t really what’s important to him and his company either. In our workplaces, both problems and tools are less important than solutions. Solutions are such a big deal that companies milk them for everything they’re worth, even socially engineering more problems for their solutions to fix than consumers knew they had. Legacy solutions are propped up for years because a new solution would be too expensive. Wheels are not reinvented. And neither are employees’ brains.
To maximize learning, we need a continuous flow of new problems sparking new solutions. We need to keep the solving going. This can only happen in the frivolity of an academic setting, where we are not concerned with costs and efficiency like our profit-minded friends. Furthermore, problems can never be primary if we don’t own them, if they come from our clients instead of ourselves.
So, if workplaces aren’t the best place for expanding our brains, what can we do at schools to make sure problems are primary? I don’t have an answer, but I know what I would like school to look like. A few years ago I taught a team-based, open-ended game development class. At the beginning of the semester, I asked everyone to draw an avatar representing how they wished to contribute to their teams. I drew an avatar too: I was the “Libarbarian,” with rippling chest and arms like tree trunks. But more important was the arsenal of books behind me. I wanted my role in this class to be clear to my students: I wasn’t in this to flex my knowledge muscles and dump lessons on them, just as a librarian doesn’t just dump books into your bag. Instead, you and the librarian have a conversation about your intellectual pursuits—your problems—and the librarian connects you to resources.
Ignore the disproportionate head. In this class, we were trying to knock down the crippling perfectionism that turns us away from opportunities for new learning.
Owning and Knowing
In chapter 3, diSessa recounts a workshop that he put on for teachers. At the beginning of the workshop, the teachers rebelled, stating that they already knew that university academics could do interesting things with Boxer. They rejected the canned lecture about others’ creations and wanted the workshop to focus on making sure they could do interesting things on their own in Boxer. The author writes, “Owning and knowing are fraternal twins. Owning leads to knowing and vice versa.” To feel like they knew Boxer, these teachers felt like they needed ownership of the lesson.
Computer science is a field where ownership comes naturally. I am making stuff, often starting with a blank code editor, and I care about that stuff so much I end up learning a lot. I am not just observing the natural world and trying to bend it to my will. I feel sorry for my friends in the hard sciences who spend more time observing than making. Sadly, though, I don’t think these folks think the ownership we enjoy in computer science leads to the kind of knowing they care about.
For example, last week my university held a poster day for the many student research projects that have been going on throughout the year. A couple of students had been working with me on Madeup, and we designed a poster that had nothing but images of 3D models that we had built on it. There was no null hypothesis, no table of data, no talk of methodology. When we submitted the poster for printing, the printing service expressed concern regarding our content, suggesting we print a cheaper banner since what we had didn’t look like a real research poster. We ignored the suggestion. During the actual poster session, some visitors said that our project didn’t really sound like research. I must have been sick the day in school where we learned what real research looks like, because this isn’t the first time I’ve heard comments like these.
We didn’t fit the expectations of research because of all the ownership that we had to get through first. We were building a complex piece of software that didn’t exist before. We couldn’t just go out to a park and count birds. We couldn’t just measure silt depth every week at different locations along the river. We were so caught up in generating the object of study that we didn’t have any time left over to study it. But that’s okay, because I gained a lot of new knowledge simply writing Madeup.
Logo’s Wane
In Turtle Geometry, diSessa and Hal Abelson provide a thorough discussion of using Logo to think about math and science. The book was published in 1981, before Logo’s wane in popularity. In the much later Changing Minds, published in 2000, diSessa explains why he thinks Logo didn’t bring about the educational revolution that some had predicted. He says that a new computational medium must do two things to achieve success:
- It must support menial, practical use.
- It must support a learning-use cycle, by which he means that as we learn the medium, it becomes more useful.
Logo, he claims, met the second requirement just fine with young learners. The first requirement is where it failed—at least with teachers. I never had the privilege of learning Logo in grade school, but I think I can understand why teacher buyin was never achieved. Everything I read about Logo focuses on its turtle drawing capabilities, and while turtle drawing is great for learning math and computer science and making 2D art to hang on one’s refrigerator, once you move past that, what you have left is a general-purpose programming language with no obvious application. Logo as a turtle-drawing language enjoyed a sweet but limited run. Logo as a general-purpose language was bound to suffer the same fate of being ignored as I believe all of our general-purpose languages will suffer.
This post mortem frightens me a little bit as I consider my own work on a Logo-like environment. But I’m comforted by two things:
- Many projects are labeled failures simply because they don’t meet their own goals. Nevermind the positive outcomes your project did achieve, if you don’t meet your own goals, your project is a failure. Logo was demonstrably excellent at motivating students and teaching programming concepts. But it was billed as a tool for teaching general problem solving, and when proving this quality became difficult, the criticism began to pile up. The good news is that I do not believe Madeup to have any particularly revolutionary value and have not been in the business of overselling it. Madeup is a simply a platform for computational making.
- From a teacher’s point of view, the virtual domain of Logo is a perhaps bit too artificial. The output of Madeup is, I believe, more menial and practical. We can make things that don’t just hang on a fridge. I think teacher buyin is more likely because we can produce tangible objects.