As a graduate student, I rarely lack enthusiasm about the amazingly powerful and profoundly cool ways of computer science. But I’m still learning about how to communicate that enthusiasm in a way that’s entertaining and informative. I often feel a disconnect between what we can feasibly expose K12 students to through instructive activities, and the complexity of the technology that increasingly surrounds us. As researchers and/or engineers, surely, we ought to be able to bridge this — by being better storytellers.
Everyone loves history. Behind every thing that exists as an unapproachable black box has a history that explains how it came together from smaller parts. History can be a great way of making more tangible the oblique ways in which technology emerges into existence. Especially with a field as young as computer science, surely, there is a wealth of entertaining and relatable stories of how the digital world came to be as it is. Why do we drag a disk to the trash bin to eject it on a mac? Why is the mouse called a mouse? What was Y2K, anyway? The delightful idiosyncrasies of our field are still fresh in wikipedia pages, and we really ought to take advantage of that.
Quick poll / show of hands. Last year, I took a class on communicating science to the public, and audience engagement was a recurring topic; although we all agreed it was generally a good idea, the question of how is more difficult to answer generally. For example, I like to open the topic of machine translation by asking, “when do you think was the first time a computer was able to automatically translate from one language into another?” For a small group, it’s a good question for short, simple answers that can be shouted out. For a larger group, this kind of question can be made into a show-of-hands: “Raise your hands if you think this happened before 1980. Keep them up if you think it was before 1970… 1960… 1950…” The answer is 1954, which is often lower than most expect, and helps build interest in the topic.
Make declarative statements into questions. But how do you figure out when to ask these questions, and which questions to ask? I like to follow one simple rule: when in doubt, replace declarative statements with questions. Have an extra few minutes? about to say something along the lines of, “___ works using ___?” Consider instead, “how do you think ___ works?” or “raise your hand if you think ___ requires ___? how about ___, would it need that?”
We’ve met as a class twice, and as we discuss computer science education, we increasingly speak of abstract definitions of computer science is, what computational thinking entails, and so on. The topic runs away into definitional vagaries of problem solving, miles away from the tangible — and really quite approachable — topics of just how the black-box gadgets in our lives work, and how they could work better. Because that’s the one of the benefits of computational thinking — not only to understand and deconstruct the tools of our lives, but to create better ones.