Guided Computer Science Inquiry in Data Structures Class
March 26, 2013 at 1:57 am 7 comments
Inquiry-based learning is the best practice for science education. Education activities focus on a driving question that is personally meaningful for students, like “Why is the sky blue?” or “Why is the stream by our school so acidic (or basic)?” or “What’s involved in building a house powered entirely by solar power?” Answering those questions leads to deeper learning about science. Learning sciences results support the value of this approach.
It’s hard for us to apply this idea from science education and teach an introductory computing course via inquiry, because students may not have many questions that relate to computer science when they first get started. Questions like “How do I make an app to do X?” or “How do I use Snap on my laptop?” are design and task oriented, not inquiry oriented. Answering them may not lead to deeper understanding of computer science. Our everyday experience of computing, through (hopefully) well-designed interfaces, hides away the underlying computing. We only really start to think about computing at moments of breakdown (what Heidigger called “present-at-hand”). “Why can’t I get to YouTube, even though the cable modem light is on?” and “How does a virus get on my computer, and how can it pop up windows on my screen?” It’s an interesting research project to explore what questions students have about computing when they enter our classes.
I realized this semester that I could prompt students to define questions for inquiry-based learning in a second computer science class, a data structures course. I’m teaching our Media Computation Data Structures course this semester. These students have seen under the covers and know that computing technology is programmed. I can use that to prompt them about how new things work. What I particularly like about this approach is how it gets me out of the “Tour of the Code” lecturing style.
Here’s an example. We had already created music using linked lists of MIDI phrases. I then showed them code for creating a linked list of images, then presented this output.
I asked students, “What do you want to know about how this worked?” This was the gamble for me — would they come up with questions? They did, and they were great questions. “Why are the images lined up along the bottom?” “Why can we see the background image?”
I formed the students into small groups, and assigned them one of the questions that the students had generated. I gave them 10 minutes to find the answers, and then report back. The discussion around the room was on-topic and had the students exploring the code in depth. We then went through each group to get their answers. Not every answer was great, but I could take the answer and expand upon it to reach the issues that I wanted to make sure that we highlighted. It was great — way better and more interactive than me paging through umpteen Powerpoint slides of code.
Then I showed them this output from another linked list of images.
Again, the questions that the students generated were terrific. “What data are stored in each instance such that some have positions and some are just stacked up on the bottom?” and “Why are there gaps along the bottom?”
Still later in the course, I showed them an animation, rendered from a scene graph, and I showed them the code that created the scene graph and generated the animation. Now, I asked them about both the animation code and the class hierarchy that the scene graph nodes was drawing upon. Their questions were both about the code, and about the engineering of the code — why was it decomposed in just this way?
(We didn’t finish answering these questions in a single class period, so I took pictures of the questions so that I could display them and we could return to them in the next class.)
I have really enjoyed these class sessions. I’m not lecturing about data structures — they’re learning about data structures. The students are really engaged in trying to figure out, “How does that work like that?” I’m busy in class suggesting where they should look in the code to get their questions answered. We jointly try to make sense of their questions and their answers. Frankly, I hope to never again have to show sequences of Powerpoint slides of code ever again.
Entry filed under: Uncategorized. Tags: computing education, data structures, inquiry-based learning, learning sciences, science education, teachers.
1.
Daniel Hickey (@dthickey) | March 26, 2013 at 2:32 am
Mark–
I believe content can always be problematized to support inquiry. You just have to look at the content from the perspective of the learner. Your conclusion that they don’t have problem to guide their initial inquiry follows from the experts perspective. But if you ask students to generate different ways of tackling the problem, you can support inquiry by asking them to ponder how their approach will impact how they learn.
I learned this from Randi Engle (RIP) and I think it will prove to be part of her enduring legacy.
2.
Mark Guzdial | March 26, 2013 at 9:55 am
Hi Dan,
I agree that we can encourage students to invent questions for inquiry in any domain. I need to learn more to be convinced that we can get students to invent questions in any domain that lead them to our learning goals. I see how we can be successful given an appropriate context, such as the design problems in Kylie Peppler’s, Janet Kolodner’s, and Yasmin Kafai’s work. A good design problem can provide the context for students to find a question that leads them towards curricular goals.
Jens’ comment points out the critical problem in computer science — the computing is invisible, locked-away inside the interface. I need to expose the computing in order to “problematize” (good word!) the content. For example, one of the concepts that we want students to learn in an introductory course is that the computer never gets tired iterating, and we can get the computer to iterate over a process for a set number of times (e.g., a for loop) or until a condition is met (e.g., a while loop). When I talk to novices about this concept, they don’t see why we would want a computer to iterate. “Why would I want the computer to fetch the same Web page or to open a picture over-and-over again?” The iteration is only useful when you get below the application surface (e.g., for all pixels in a picture, for all characters in a word, etc.).
Do you have a paper by Randi that you can recommend to learn more about this idea? I’m open to learn that I’m wrong.
3.
Daniel Hickey (@dthickey) | March 26, 2013 at 11:34 pm
It is not that you are wrong so much as that there are opportunities for inquiry that are hard to see at first, particularly if you start from the perspective of the expert rather than the learner. Engle and Conant (2001) in Cognition and Instruction is what informed me. Your example of iteration is a good one. That is a pretty abstract concept to novices right? If you have students pick and execute assignments that are interesting to them, they can then reflect on whether or not that context is more or less useful for learning the abstract concept of iteration. They may be perplexed at first but as they context become more salient, they can start to discuss and see how the concept of iteration takes on different meaning in different project concepts. This anchors their unfolding understanding to those concrete contexts, which should make it more useful.
4.
Mark Guzdial | March 27, 2013 at 8:30 am
Thanks, Dan. Cindy Hmelo-Silver sent me the reference yesterday, and the paper is now in my to-read pile.
5.
Jens Mönig | March 26, 2013 at 8:52 am
It’s one thing for a user interface to hide away the underlying computing, and another to lock you out.
I have a hunch that hiding might be okay if it can improve accessibility and still spark curiosity. The question is, does an interface let you look at and tamper with what’s under the hood? After all, even if an application is open source it can be very hard to make meaningful connections from reading the code to how it behaves at the surface. For me, exploring Smalltalk was a rare exception, a life-changing experience. I wish more interfaces were user penetrable like a Squeak image.
And – since you mentioned Snap! – let me point out that we’ve tried to keep at least some of Squeak’s spirit alive in Snap’s GUI. By shift-clicking on the logo you can switch to “dev mode”, which lets you inspect, deconstruct and even modify every component and every piece of code on the fly in a Morphic way using inspector widgets very much inspired by Squeak.
Right now this is not much more than a gesture, but at least an inviting one to inquiring minds. 🙂
6.
Mark Guzdial | March 26, 2013 at 9:46 am
I completely agree, Jens. Cindy Hmelo-Silver and I talked about this distinction several years ago, when we made a distinction between “glass box” and “black box” scaffolding. I’d like to explore this further, and your enhancement to Snap sounds really exciting!
7.
Jens Mönig | March 27, 2013 at 5:35 am
“glass box” scaffolding is a both cute and fitting expression for what I was trying to say in many more words. Thanks, Mark, for the link to the ICLS ’96 Proceedings.