You are currently browsing the category archive for the ‘Computational thinking’ category.
I read a blog post recently about the use of smartphones in the classroom, and it was thought-provoking enough to make me want to flesh out some ideas. I submitted them as a comment two weeks ago, but they didn’t appear on the blog. My inquiry about whether the comment was rejected or simply lost in the ether also went unacknowledged, so I thought I’d post it here.
Smartphones Work Well In My Classroom For…
I really appreciate when students take photos of the board, so they can pay attention and join the conversation instead of copying what I’m writing. A document-scanning app (e.g. CamScanner) can correct parallax and improve contrast, making it look like you own a scanner the size of the whiteboard.
If students are working on team-sized interactive whiteboards, it can also be a great way to capture what they’ve come up with as a group, instead of having to re-copy it into their notebook.
Tablets are extra-useful for this since the larger screen makes it easier to read and annotate the photos — especially useful are EzPDF and Freenote, although obviously cross-platform support can be an issue.
I also like having students take videos of themselves solving problems or demonstrating experiments — a big help when I don’t have time to see each person or group “live.” Plus, hearing their voices as they describe their thinking gives me a better feel for what they’ve understood vs. what they’ve memorized.
The interesting thing is that many of my students, contrary to the received wisdom about digital natives, are surprisingly reticent about this. It takes a significant amount of direct instruction for students to try these approaches, even when it seems to me that it would be a huge time-saver. If I give an online and a conventional option for an assignment, the students overwhelmingly choose the conventional route (using a paper notebook instead of a blog so that their essay research is searchable… or submitting written assignments instead of screencasts… or typing instead of using speech to text for dictating papers, for example — even Windows 7 has native support that is reasonably good).
My students, for various reasons, don’t have much time for adjusting or troubleshooting their devices (figuring out where the camera stores its pictures so that the pics can be attached to an email, for example) and often do not understand that folders are hierarchical.
But I Can Drive Without Understanding Engines, Right?
The good news is, teachers who fear that their students far outpace them in skill probably have less to fear than they think. The bad news is, I suspect that we (including the students) tend to overestimate the degree to which using technology (as opposed to understanding it, or directing it) is inherently useful.
It’s a bit like knowing how to drive a car but not understanding that pressing on the accelerator is what uses up gas and increases the braking distance. You can make the car go fast, but you probably can’t figure out whether going fast is a good idea at the moment. Maybe you follow the speed limit diligently without being able to judge whether it’s prudent under the conditions; maybe you don’t follow the speed limit because you don’t know of any reason for its importance. Besides being dangerous, both approaches are unthinking — abdicating responsibility to either the rule-makers or other drivers.
Making Vs. Using
One approach that seems to be having a lot of success is systematically teaching students to become makers and fixers of classroom technology instead of users/consumers. I’m also excited about making programming accessible to kids. Besides improving conceptual understanding and critical thinking, this approach can help us broach the idea that it’s not good enough to be a “native” of a society in which someone else holds the reins of power. My question to them is not whether they are “digital natives” but whether they are “digital serfs.” In other words, time to start paying attention to who are the programmers, and who are the programmed.
My second year students started this semester having never written a line of code, and are making good progress in computational thinking. They are taking two concurrent intro programming courses this semester. One, which I teach, uses embedded C to program a pre-fab circuit board (this one). The other, which I’ve taught in the past but don’t now, uses Rockwell’s “ladder logic” language for programmable logic controllers.
I wrote previously about using Mark Guzdial’s approach of “worked examples and self-explanations,” and the results are very good so far. The students were very quickly able to make sense of compiler errors, decode data sheet register descriptions, troubleshoot their programs’ run-time behaviour, and combine their code snippets into novel (to them) programs. So far they can control buttons, LEDs, buzzers (using pulse-width modulation), and interrupt-driven timers.
Embedded Systems: The Bottom of the Ladder of Abstraction
I was pretty worried about introducing programming using an embedded language — I thought that working with a system that has no keyboard, mouse, or monitor would be a bit alienating, but that hasn’t been the case at all. If anything, the reverse is true — there’s something very grounded about immediately seeing your code control something outside the computer.
Look Ma, No Variables (Yet)
The other advantage of starting with an embedded language is that we were able to do the first two units (Digital I/O and Timers/Buzzers) without ever using a variable. Ergo: I was able to delay explaining variables for about a month, with its attendant conceptual minefield of data types, type hierarchy and promotion, variable scope, etc. We talked about 8-bit registers, of course, but only as “a collection of flip-flops” that are permanently assigned to a single task — starting with bits whose logical value controlled a voltage that turned on a light. This allowed the students to get a feel for assignment, sequence of execution, and timing, without getting bogged down.
In each worked example, I introduced one new syntactical item — first a while loop, then #DEFINE, then an if statement. We talked about it a bit but didn’t include it on quizzes. After four weeks of teaching the micro to do tricks like blink lights and make piercing noises, we started the official “syntax” unit. Here’s what the students can consistently do:
- choose a data type for a particular situation
- predict the outcome of a mixed-type evaluation
- predict the result of a mixed-type assignment
- evaluate logical operations with up to 4 terms — whether they’re sensible or not (examples like “Button1 == PRESSED || Button2 == PRESSED” as well as “6 && (5 < 3) == FALSE”)
- convert between case statements and if statements
- convert between while, for, and do loops
What’s Going Well
Removable chip. In the past, I’ve often noticed students having trouble distinguishing between what’s “inside” the “computer” and what’s “outside.” For example, they will have trouble distinguishing a set of LEDs from the microcontroller pins that control them. Using a demo board with a socketed through-hole microcontroller helps clarify this a bit — especially since our programmers are the out-of-circuit “burn and learn” type where the IC has to be removed from the board and placed in the programmer. With in-circuit programming, students tend to see a circuit-board as an undifferentiated lump — the entire PCB appears to them to be the micro.
Cross compiling. It can be hard to talk about what a compiler really does when students see compiling as “running a program” and executing their code as “running a program.” In an embedded system, the compiling happens on the desktop computer, and the executing happens in a circuit-board on your bench.
Two languages. Comparing two vastly different languages and platforms (microcontroller C vs. PLC ladder logic) helps us talk about what is a general concept of programming and what is a specific feature of a platform or manufacturer. Because ladder logic is interpreted in something called a “scan cycle” (it does not execute every instruction one after the other), it was especially helpful in sorting out flow control.
Worked examples. As Guzdial suggests, making students type in their code makes them very attentive to syntax, capitalization, etc — without me having to sedate them with an explanation. Normally I’d be inclined to steer them away from those superficial features, maybe started with flow charts or something. But they seem to really benefit from thinking about why those symbols are there. The worked examples also mean that students are building up a library of code snippets that they can string together and modify.
Individual examples. Since every student gets a different code example, they are oddly entertained by typing them in to find out what they do (if everyone had the same one, it would only be entertaining for the first person).
Free online textbook. It’s nothing fancy, and there a few grammar mistakes, but the students have been making good use of it, and the diagrams are especially good. Students refer to it for syntax and use it to understand the peripherals that are available and what they do.
Problets. My students are addicted to these online exercises for evaluating and correcting tiny fragments of code. These have really helped students make sense of the sequence of execution, and how to keep track of changing variables. The feedback you get when you make a mistake is unusually helpful (for a compiler). Plus, the author makes them available for free.
I’ve just agreed to be the head judge for a LEGO robot competition for high school students. In light of my workload this year, that probably means I have lost my marbles. However, I couldn’t resist. I judged last year and found it extremely interesting. I’m looking forward to meeting others in the province who love the combination of kids and robots, working with the judges to develop a consistent way to score teams’ performance, and just getting off campus more. Of course, if I ended up recruiting kids into my program, that wouldn’t be so bad either).
Acadia University hosts the local FIRST LEGO League competition for 9-14 year olds, which is co-ordinated internationally. Four years ago, they decided to run an independent high-school competition so that kids who had aged out of FIRST could continue to compete. To see the details, go to the competition page and click on High School Robotics.
My responsibilities are
- defining the challenges (this needs to happen ASAP)
- getting the word out about the competition, which is in February
- answering questions from school teams about the competition and the challenges
- helping with orientation for the judging team
The teams borrow or buy a robot kit and get three challenges to complete — things like moving pop cans, dropping balls into containers, detecting and navigating around obstacles, etc. The teams get two runs through the course, with time in between the runs to make changes to their robots.
How Teams Are Evaluated
- An interview with two judges before their robot runs the course. They have to explain their code, demonstrate their robot, and answer questions about their process
- An interview between the two runs. They have to explain what went well, what didn’t go well, and how they are going to improve.
Things I Noticed Last Year
- The teams tended to be well balanced — either the students were all able to explain each aspect of the robot, or each student was able to explain one aspect in detail. There was the occasional student who didn’t seem to be as involved, but not many.
- The coaches varied widely in their degree of involvement. There were some programs that I was pretty sure the teams wouldn’t have come up with on their own, but they seemed able to explain the logic.
- Almost all the robots performed poorly on the competition field, with many of the planned features not working. This surprised me, since organizers publish the exact dimensions and features of the competition field months in advance. Surely if the design was not meeting the requirements, the students knew that in advance…
- Some teams were able to articulate what exactly was not working after their first run (for example, the robot ran into the wall and then couldn’t turn around), and some teams were not.
- Regardless of their ability to diagnose the problem, most teams were not able to troubleshoot in a logical way. The changes they proposed to improve for their second run often addressed an unrelated component — for example, if their robot had incorrectly identified the difference between white and black cans, they might propose to change the motor speed.
For those of you who’ve participated in robotics or similar competition, any suggestions? I’m especially interested in these questions:
- What helps new teams get involved?
- What features of the challenges can help kids think independently and algorithmically?
- What practices in the design or judging can promote more causal thinking?
- kept working after the end of class
- asked significant questions (“What’s the difference between MethodX and MethodY,” “What’s the difference between colours and pixels?”)
- turned in unusually ambitious first programming assignments (50-200 lines of code)
- made sense of abstract concepts (“Isn’t a function just a way to name some lines of code?”)
- reported finding it “surprisingly” enjoyable
Part of this is no doubt attributable to the “media computation” approach that he uses, which seems like a very cool way to introduce people to programming. Unfortunately I am stuck with a 2-line LCD that has timing issues I haven’t figured out completely, so we’ll be starting with blinking lights. But there are definitely aspects that I can incorporate, including having students
- type in examples
- develop line-by-line explanations for themselves
- compare examples that differ in small ways
- compare their explanations to others’
- plan and execute a change to the program
You’ll notice that the “self-explanation” part has two columns: one titled “Explain in English what this means” and one titled “Why does it have to be here?”
When I’ve tutored for programming courses in the past, I’ve noticed that students often write unhelpful comments such as
index = index + 2; // Add 2 to index
For a fluent programmer, these are frustrating. Not only did I waste time reading something I already knew, but now I have to spend time figuring out why that line is there. My working hypothesis is that a beginning programmer needs that translation, just as a beginning student of Italian may need to translate statements into English before they can begin to interpret them. When beginners are forced to comment their code, they write what they think, which is a literal translation. I’m hoping that by making space for that translation (what Tovani calls “holding your thinking”), it will enable students to go to the next step and write something that will continue to be helpful when they stop needing every line to be written in two languages.
I’ve also asked them to document the differences between their code and the code of the person on either side of them. The example programs differ only in tiny ways — maybe a different pattern of LEDs is turned on, or there is a slight difference in the I/O bit mask. I was deliberately keeping it simple for the first run through, as we worked through the hiccups.
The next step is for students to summarize the meaning and function of the new ideas we learned (for example, the difference between a “port” and a “register”). Finally, I ask them to plan a change to the program, tell me what their plan is, and then make it happen (this order of operations is designed to prevent students from making a random change, documenting its effect, and claiming that it was their plan all along).
Since it was our first time trying this, I walked the students through it as if I was a student. I used an example program (shown in the document above) and annotated it on the board. There are a few elements I told them they were not responsible for explaining, and I skipped over them. One was the “void” keyword used as the return type of the main function (I didn’t even want to get into data types, let alone functions, or what the main function would be returning that value to).
I also didn’t explain the infinite while loop in much detail, except to confirm with them that 1 would always equal 1, so the condition would always be true (all the while loop conditions have relational operators such as 5==5, or 6>3, based on my theory that it’s easier for a beginner to see that those are true than to make sense of while(1); or something like that).
We only had time to get about half-way through this exercise in class, and so far the results are promising. I have very little to compare to, since I haven’t taught this particular course before, but I was encouraged that they were attending to detail, looking for patterns, and making inferences about the system’s requirements and possibilities. Some of the questions that came up:
- Does it matter if things are on the same line/how many tabs there are/how many lines between commands?
- Do you always need the semicolons/stars?
- Instead of using while(5==5), could I use while(x==5) and make x equal to something and change it?
- If a pin is set as analog, does that mean it needs an analog input? What if it’s set as a digital input? Does it need digital input?