How to increase thinking in the computer science classroom

Photo by NESA by Makers on Unsplash

I’ve always believed that students should be made to figure things out for themselves. Knowledge is deeper and longer-lasting when it is created rather than received. This, by the way, is classic constructivist pedagogy. But there are actually some types of knowledge that our students can’t — and shouldn’t — construct themselves. It’s important to know the difference: when do we make students think, and when do we just tell them the answer? I can finally articulate the distinction in a way that feels right.

It began when I attended a workshop to learn how to teach in Snap!. At one point, the instructor asked us to guess the name of a particular section on our screen. After some silence, he asked, “Well, what’s the place where we keep animals on a farm?” The question bothered me, but I didn’t know why. I was frustrated with myself for not knowing the answer, but I was also vaguely annoyed at the question itself. (The answer, by the way, is the “corral.”) If it’s good to ask your students lots of questions, then why did this question bother me so much?


In search of an answer, I went back to my science teaching background. In Modeling instruction, students manipulate materials to figure out for themselves how things work. After they have developed their mental models, the teacher gives them the conventional words and symbols for the concepts they have constructed. For example, a student might infer, after a series of observations, that there is a type of energy associated with motion. The teacher would then explain that physicists call it “kinetic energy.” We use the word “kinetic” by convention. We could call it anything, and it wouldn’t make a difference — as long as we all agree to use the same word, so we know we’re all talking about the same thing. What really matters is the conceptMeaningful student engagement comes from discovering and articulating the concept, not from guessing the word we conventionally use to denote said concept. My physics students know the distinction between scientific law and scientific convention. They work to discover the former, and I give them the latter. The convention then facilitates their communication with others, which enables us to build jointly upon our shared knowledge.

So how does this translate to computer science? When teaching coding, I never make students guess syntax. Instead, I ask students to describe their algorithm (what they want their program to do, step-by-step), and then I guide them to the resources that will give them the coding syntax they need. For example, a student learning Python for the first time might say, “I want to write a program that greets the user.” She then translates this into an algorithm: “My program will ask the user her name, and then it will output the phrase, ‘Hello, [user name]!’” At this point, the student has done the cognitive pre-work and it is time to write the code.

There are still two ways I might go from here. I could either (a) suggest that the student write “print(‘Hello, ’ + name)” and then run the program, or (b) have the student do a google search for how to output text to the terminal in Python. So when do I use (a) versus (b)? It depends on the case at hand. Approach (a) will free students’ minds to focus on the logic of the code. Approach (b) will help students become self-reliant coders who can find and use documentation appropriately.

  • Case study for (a), giving students the syntax: We just started learning Python in class. A student has defined the variable name and now wants to debug a line of code that says “print(‘Hello, ’ name)”. His understanding of string manipulation is nascent and thus tenuous. It might be distracting to do a google search, and he might not even know what terms to google. So I tell him that in Python he can “concatenate” strings using the “+” sign. With this new information, he’s off and running. He can now use this coding convention to build further (for example, by figuring out how to get that exclamation mark to appear at the end of the sentence).
  • Case study for (b), having students look it up: Now a few days have elapsed in our class, and another student wants to make multiple “print” statements all output on the same line in the terminal. This is outside the scope of the day’s learning target, but the student has already met the day’s objective and is excited about this extension. Because she already has command of the concepts at play, I challenge her to find online the documentation she needs — and then of course to share what she learned with the rest of the class!

To reiterate: in neither case do I elicit syntax conventions from students (eg, “What symbol does Python use to put strings together?”) Doing so will only alienate inexperienced coders while reinforcing the rote knowledge of those who happen to know it already. And then neither group of students is doing any real thinking. Syntax guessing distracts from real thinking — because it doesn’t matter whether the Python convention is to use a plus sign, ampersand, hyphen, or any other character to concatenate. What matters is knowing what concatenation is, and when to use it.

Good teaching does not mean turning everything into a question. It doesn’t really matter what something is called; what matters is how we use it to achieve a goal. By giving our students the basic conventions (like “this part of the screen is called the ‘corral’”), their minds are freed up for meaningful problem-solving. Don’t make your students guess syntax. Make them think instead.

This article is written by Elissa Levy and Posted on Medium/Upperline Code

Recommended Posts

No comment yet, add your voice below!

Add a Comment

Your email address will not be published. Required fields are marked *