Last week, I was away on a Middle School field trip, and so I left my CS II class of 6 students to their own devices. I gave them an online quiz to complete and told them they could use a book, Google, whatever, in order to answer the questions. They chose to show up in my classroom during our regular class meeting and work together. For the written answers, they were the same. They asked me first thing if I noticed anything unusual about the quiz. To which I responded: you mean like how everything was the same? It was funny.
Their longest answer involved writing an algorithm to make a sandwich. While most of them wrote a paragraph explanation, one student posted an image as a response. The image is clearly what everyone based their answer on. But you have to admit, it’s good CS (click to see bigger):
After class today, most of the students stuck around to do more computing while I mostly checked email. One student is working on “I survived the CS I exam” t-shirts. Really, I think they should just teach the class from here on out.
Back in the day, computers were fairly stripped down. To interact with them, you used the command line. To code, you used a text editor that didn’t look that different from the command line (emacs, pico, vi). Even when gui interfaces came along, to make web sites, you often just popped open a text editor (which always functioned as a plain text editor) and then uploaded your files through an FTP client or through the command line (which did more often than not). Many great tools came along that somewhat simplified this process, but some also hid this process, so that if you used, say, a wysiwig html editor, you really didn’t understand that when you saved a file, you were also uploading it.
Nowadays, people don’t edit straight html that much (outside of some professional environments). Now, they type in boxes (as I’m doing now). If you want to teach writing straight HTML, the tools are sort of working against you. TextEdit on the Mac requires setting it to plain text to make it HTML safe, but even it chokes a little on things like apostrophes. Other text editors do a good job, but then one must use an FTP client or command line, which is probably fine if you’re working with, say, 17-20 year olds, but is painful if you’re working with 13 year olds.
Teaching at this level means really thinking about the tools you’re using and whether or not they’re getting in the way of learning the things you’re really teaching. At the college level, maybe you start out with the “tools of the trade”, but at younger levels, starting with Eclipse or IDLE can lead to frustration before students have even begun writing a line of code. We’re not teaching software engineering after all. We’re teaching students how computers work, and how we can make them do cool things for us with just, as one of my students put it, “some random letters and stuff.” I’ve thrown my high school students into command line stuff and for some of them it’s mind blowing and painful. Which is why I’ll switch to something that’s much more straightforward and closer to how they already use their computers. I do want students to understand the innards of computers, but I don’t want them to be frustrated by it. I want them to be fascinated by it. So we’ll use tools that are easy while exposing some of what those tools hide.
Most students come into a CS class thinking that the real challenge of Computer Science will be learning syntax for a particular programming language. And while curly braces and semi-colons do indeed sometimes trip people up, the real challenge is creating the algorithm you want to code in the first place. You can always look up syntax, but constructing the algorithm is where the hard work gets done.
My CS II students were asked to write a program to encode a message and then write a program to decode a message. The pattern they were to use was a Caesar cipher (shifting each letter over a few in the alphabet), so that the decoder could more easily be written. This is a program I thought they could have done in a single class period (1 hour and 15 minutes), but so far, we’ve taken about an hour and a half (end of one class plus all of the next). I wrote the programs in 4 or 5 lines each in about 15 minutes total. This is supposed to be review, not new material.
A couple of things come to mind. I think last year I held their hands too much, helping them come up with code snippets to solve their problems, so they can’t remember, for example, how to loop through a list. But two, I think they didn’t abstract out from the coding they did do to the algorithmic level. They’re not really breaking down the problem into parts.
Here’s how I broke it down:
1. Get a string via input.
2. Loop through the string and change each letter according to a set pattern.
3. Save the resulting string.
That’s pretty basic, though that second item can get broken down further, because you have to figure out how, exactly to tell the computer what the pattern is and do the substitution. I’m not allowing the use of dictionaries/hash tables yet, so that piece is a bit tricky, and there are at least two ways to do it that I thought of off the top of my head, but there are probably infinite ways!
They have a quiz on Wednesday, which is open book, but I think I’m going to add an algorithmic thinking question to it and discuss it with them thoroughly. They’re not going to make it through object-oriented programming if they can’t break down their problems into parts. I’ll let you know how it goes.
We’ve already talked about algorithms in CS I, but seeing what’s happening in CS II reminds me that I need to really drive this concept home. I have changed some things in CS I that I think will work better, including more pair programming. Dawn found that group work really helped. Talking through the possible strategies and having a peer steer you correctly can help. So, we’ll see.
This year in CS I, I decided to start each class with a current event article. We did this last year in my Race and Gender class, and it was a great success. So far, we’ve discussed the naked photo fiasco, the rumor that Twitter might change its feed to be more like Facebook’s and filter stuff, and today, net neutrality.
We’ve had some great conversations around these issues. We’ve talked about how hacking happens, from social engineering and brute force attacks to code cracking. We’ve talked about how algorithms shape what we see on Netflix, Amazon, and Facebook. And we’ve talked about how networks work.
And that’s just in the first 10 minutes of each class. I really like placing what we’re doing in context. We haven’t started any coding yet, but I plan to continue the current event thing, with the students taking over in a couple of weeks.
Saying that CS is everywhere is one thing, showing that it really is, is another!
Once a month or so, back in the early days of blogging, this question would be posed by a male blogger. And then, the female bloggers would respond, um we’re here, you just don’t link to us or include us in your lists. Because many female bloggers were writing about so-called women’s issues–family policy, sexism, parenting, etc.–men just didn’t pay attention. And so women were made invisible in the new economy of blog networks.
I think we’re past that now, mostly, thanks in large part to those female bloggers, who were good writers and who insisted that the issues they cared about we’re important to everyone. It took some work.
MAKE Magazine featured a where are the women story about makerspaces, written by Georgia Guthrie who runs my local makerspace, The Hacktory. I have been to many events at The Hacktory and it has always had a good mix of men and women. She’s done a fantastic job of making the space welcoming.
In the article, she talks about ways that women ar made to feel like they aren’t good at maker activities. Often, they’re deterred by teachers. I got lucky in middle and high school. My teachers would say things like, maybe you should consider being a genetic engineer. And even when I struggled, they assumed I would figure it out, and helped me and never indicated that my struggles meant that I couldn’t do math or science. My trouble began in college, when my science professor scoffed at me taking the real intro rather than the one for non-majors, so I dropped and never took science again, except the one required mom-major class.
As a teacher myself, and a teacher of girls, I am careful about what I say to girls, especially those who struggle, or who say, I’m not good at this. I always compare CS to sports or an instrument. It takes practice. If you’re in a coed environment, there are often other things you have to do. Build girls confidence and call on them when they have the answer. Praise their work. Make sure the boys don’t take over, especially in group projects. Make your classroom inviting. Don’t have posters featuring just men or that mainly represent interests for boys, like first person shooters. Consider varying your assignments to appeal to girls. That war assignment you do might leave girls cold. Try having an art or music assignment, too. Also make sure your assignments don’t emphasize sensitive issues for girls: food, body size, looks, etc. Don’t have a data assignment that requires students to weigh themselves, for example. And consider having your students do some research on the gender gap. Of course, you’ll have to be prepared for a challenging conversation about that. Some boys will insist that the gender gap exists because women are not as good at stem or that they’re not as interested. Bring in an expert if you want.
To be sensitive to gender issues in your classroom means thinking about it and examining it in everything you do. But you can improve the landscape for your female students with some small changes and perhaps gain some new students in the process.
Assessment is one of the hardest things teachers do. Yes, sometimes we can grade tests and there are right and wrong answers, but often, we’re trying to assess and provide feedback on how a student thinks. Or we’re assessing the process of how they got from point A to point B. I like how Dawn address this issue in this post, using a pre-assessment as a starting point.
Standards-based grading helps here a lot, giving some good language for the students to understand where they are: you don’t know this at all, you’re learning, you’ve almost mastered it, you’re a ninja (to simplify). After going through her papers and assessing them, she came up with a list of things the students need to understand. She looked at their misconceptions closely and determined what exactly they were. Such a great idea! Here are here conclusions:
Some common misconceptions I ran into that I’ll need to watch as we go through the unit:
– Not understanding that one block = one instruction
– Not knowing what variables represent or keeping track of more than one variable
– Changing variables, assigning variables, substituting values in place of variables
– Not understanding what a Repeat block does
– Not understanding “if” and especially nested “if” statements
– Not seeing that instructions are run one at a time, starting at the beginning and following an order of execution
– Not understanding that the instructions inside a Repeat loop can do something different each time depending on values of variables and conditional statements
– Thinking of the narrative of a game instead of rules that are followed
All of the above things are things most of us teaching CS see quite often, but it’s nice to see it in a list like this. When I go over quizzes and tests, I sometimes make lists like this, of things that hung people up.
More importantly, Dawn addresses the thinking and learning strategies that have gone awry:
– Not actually reading the prompt on an assessment
– Not answering all parts of a question
– Being sad about not understanding a pre-assessment
– Not writing in complete thoughts, let alone complete sentences
– Getting lost and giving up and lacking strategies to understand the text
The one about being sad and the one about getting lost really get to me. Those are the things that sometimes stop kids in their tracks and keep them from learning the material even when they are capable of doing so. In Computer Science (and in other STEM fields), that feeling of being lost or sad (after a test or other assessment) often drives people away, especially women, who are more likely to blame themselves rather than appreciate that there’s a learning curve and that they’re at the beginning.
I’m looking forward to seeing more from Dawn on her assessment strategies. It’s something I think about and work on all the time, especially those thinking pieces.
I’ve been building classes and syllabi for over 20 years. Which is kind of freaky. I still feel new to it somehow. I think because I challenge myself to do it better every year. Putting classes together is hard work. I was explaining this to a non teacher the other day. One thing I said was that often it takes 2 hours to plan an hour long class. Which is sometimes true though thankfully not always. I thought I’d share my process and get others to share. I’m curious about the many different ways of thinking through building a course.
I begin, usually, by thinking about the end. Where to I want students to get? I often think about a capstone project an what they should be able to accomplish by the end of the course. Then I think about how to get there. I think about themes or topics and what order to go in.
Here’s an example. I’m still thinking through my 8th grade elective. It’s a CS/maker course and I want my students to be able to create a complex project that involves something physical like a robot or lights or any object and something digital like a program that drives the physical or that he physical drives the digital. So I’m thinking of themes like this: digital design, physical design, from digital to physical (programming an object), from physical to digital (using sensor data). There are sub themes in there like interface design and working with data.
And that’s what I do next. I start deciding what exactly we’ll do each day. Will we need to read something before class? What activities will we do? How much explanation will I need to give and what supporting materials will I need to have on hand? I try to map as much of this out ahead of time as I can, but sometimes I’m planning these single class periods the day before. And sometimes things change. Projects take longer or shorter than I thought. A snow day hits. The students really want to learn X. And so I adapt.
Adapting is key. Though I always have a plan, I always try to gage where my students are and where they want to go and adjust accordingly. I want them to have a sense of where I think we might go but I try to make it clear that it’s their journey and they have some say over how we get there.
Futurists and others hope for the day when everything we do is automated, when humans are living a life of leisure while our robot and AI servants do our bidding. This is not my area of expertise, and certainly, I’ve seen computers become capable of helping us do a multitude of tasks. Mapping, facial recognition, search, building cars, driving cars!–these are all things computers and/or robots are currently doing, and in some cases, doing well. People are also using algorithms to create art and poetry, activities we might think of as being uniquely human. So these things seep into areas that we might not think they can or even should.
My good friend, Audrey Watters, often writes about the ways that education relies on computer data-crunching to evaluate student learning or teacher performance. Now, I’m a big fan of data and what it can reveal, but I’m no fan of letting a computer program evaluate something as messy as learning all by itself. For one thing, most of these programs evaluate learning strictly through multiple choice tests, which can only tell you so much about how well a student is doing. Personally, I weigh process a whole lot more than product, which is what those tests evaluate without regard to process. I have no idea how a computer program is going to evaluate a project.
My former career was as a writing teacher and the grading of papers by computer is a fantasy many have longed for to alleviate the long hours of assessing student writing. Essay graders exist, but they aren’t that good, taking long words and more complex sentences as strong signals for good writing. Good writing is more than that, as anyone who writes or reads, much less teaches, knows. Still, there could be a role for computers in the writing process besides being used as a word processor or plagiarism checker. This article from Slate discusses how students respond better to computer feedback than teacher feedback. The reasoning makes sense to this for the same reasons people in general trust any data coming from a computer. Students think computers are more objective, maybe even more accurate than their teachers. And, they’re less anxious about getting feedback from a machine than a judgemental teacher. So maybe this is a reasonable role for computers and algorithms as part of the process, and not as the evaluator of the product.
Last week, Mark Guzdial wrote about the new CS: Principles course that is replacing the current AP CS course. The current AP uses Java and in fact, is somewhat focused on teaching Java, the language as much as it is about teaching CS. The change for the exam and course comes because the current setup turns off many people and it has been suggested that the current AP setup for CS is one factor that contributes to the lack of test takers generally and the lack of women and other underrepresented groups taking AP CS.
Mark suggests, however, that the new CS: Principles course and test might fail because colleges won’t offer credit for the course the way they did for the current AP, where colleges might be assured that students had a good understanding of a standard programming language. He says:
It’s reasonable to say that an AP will only succeed (e.g., students will take it) if they can get credit or placement for the exam in college or university. Typically, colleges and universities give credit for courses that are currently taught. Will we see colleges and universities start teaching CS Principles? Will they give credit for a course that they don’t teach? For languages they don’t teach?
Mark’s questions here are reasonable, but I don’t think they are the whole story. His assumption is that students take AP courses to get credit, which might speed their ability to take advanced courses or even to finish college (which would save them money). But that’s not the only, and maybe not even the main reason students take AP courses. They take them to get into college in the first place. AP is a signifier that the course is rigorous and generally at the college level. It is the most advanced course students can take in high school, and a student who has taken several AP courses signals that they are a serious student, worthy of admitting to many prestigious colleges.
I know this in part because we have no AP courses at my school, and one of the issues that raises is how to signal to colleges that our upper level courses are as rigorous as typical AP courses. We eliminated AP courses, in fact, because they weren’t rigorous enough. They were limiting, focused often on memorizing facts rather than learning to do science or history in the way that colleges often expect.
At least one commenter mentions this in the comment thread, which is well worth the read. Mark worries, in comment 30 (sorry, can’t link), that the signaling aspect of AP will miss underrepresented groups because that’s just not something they think about. Mark and others think that unless CSP will give credit for a particular course, an intro CS course or a quantitative reasoning course or something along those lines, students won’t take the course at the high school level. They might be right.
I don’t have time right now to pull the data, but I’m curious how many schools offer credit for the current AP CS course. I know quite a few that don’t, either because their CS I course is very different from what’s taught in AP or just because they don’t really offer credit for many AP courses generally. The question of the impact of any AP course on student enrollment in certain colleges and certain majors as well as whether they explore a field in high school is a complex one. Reading the comments on Mark’s post will give you an insight into the complexity. I note that there are no high school teachers commenting on that post. A shame, because that perspective, I think, would be a bit different.
One of the things I enjoy about working on a project like my dog door logging project is that problems crop up that challenge me. This is something I find fun, but my students sometimes find frustrating, so I’ve been thinking about how to present the issues of problem solving in a way that will be more appealing to my students and will encourage them to dig as deep as they need to to solve the problem and not give up.
I tend to approach problems in a step by step fashion. As I’ve built this dog door project, I’ve done it one step at a time rather than trying everything at once. First, I tested the tilt sensor itself to see if it would work, printing it’s state to the monitor. The wiring and programming for the tilt sensor have been well documented (thanks, Adafruit!), making this step fairly straightforward. Understanding the programming language and how circuits work allow you to change things up if needed, but the basic tutorial gets things off the ground quite nicely. Early success is important!
The next step was to figure out how to save the data from the tilt sensor. This involves thinking about a couple of things. First, what does the data coming out of the sensor look like? Is it a string? A number? Here’s where tutorials sometimes break down. The tutorial I used lit a light when its state changed. I needed to print text somewhere, preferably in a format I could use elsewhere to create a graph. I had in step one, printed to the serial monitor, adding a single line to the tutorial code. I actually ended up making my own string, so that “Up” printed to the screen when the “door” was “Up”. Basically the tilt sensor registers a high or low value of electricity, similar to an LED receiving a high or low value of electricity, so I just converted the high or low value to the string “Up” or “Down”.
There’s a lot to unpack in just that one solution. I think we underestimate that when teaching students. Understanding what’s coming out of a function is challenging for most. Knowing that printing to a file requires a string or a number and that other data types might not work is a pretty big step. And then you have to figure out how to convert your data to the right type if necessary. Also, you have to know that some sensors might actually give you numbers and then you don’t need to convert! Crazy.
So I’m printing to the screen, but not saving the data anywhere. How do I do that? How do I do that with what I have on hand? To the Google machine! As I mentioned yesterday, I discovered that the Arduino can store a small amount of data (512 bytes). This was a test of two things: 1) that the data can be saved and 2) that I could read the data later and see that it was useful data. Again, the documentation on this was good, but I had to know how to search for that. I searched “how to save data on an Arduino” by the way. And I got this, which led me to this. And just this step is a challenge for many students. There are different kinds of memory. The amount is tiny, so one has to think about how many characters to use. It’s a good lesson, but could be frustrating. And there’s a whole other process for reading the stored memory out, which requires writing another program. Phew!
In search of a more robust solution for saving and retrieving data, I went to the SD shield, a shield I’ve used before with some frustration. Most of the time, I couldn’t even get the Arduino to recognize the SD card, which has to be formatted exactly correctly for anything to work. I got past this step at least. In theory, I’m writing to the SD card now instead of local memory (a one-line change plus some imported libraries and pin attributions, maybe 5 lines total). But, the file is empty every time I look at it. No errors, just not doing what I think I’m telling it to do. And these are the issues faced by most of my students. Things are “correct” but something isn’t right. My card could be too big. The documentation does say that SD cards that are bigger than 16GB are not supported. Whatever that means. My filename could be wrong, but I think I’d get an error. Could be any number of things, programmatically or electrical or hardware.
And then I have to solve the problem of how to get the device onto the dog door itself. This is going to pose an issue. The best way to do it would be to solder everything together, and I think that’s the direction I’m headed. We shall see.
But you can see how many layers of things one must dig through to begin to solve what seems like really simple problems. To me, this is the crux of what we teach in CS. We help students methodically step through solving a problem (often a problem they designed) and then recognize the smaller problems they need to solve one at a time in order to achieve the larger solution. It’s breaking down problems into smaller parts, algorithmic thinking, and a touch of creativity, all things we’re trying to convey in CS. But it’s not always easy and I think we need to recognize the frustration that might come with discovering another mystery with each solution, the feeling that maybe there’s no bottom to this. Thinking through my own strategies for solving this particular problem reveals all the things I know that help me, things I might need to help my students learn as they bump up against these kinds of problems: different data formats, how data is read by a computer, memory types and sizes, formats for disks and files, not to mention electrical circuits and programming which are the main things we think we’re working with. I find it fun to peel back the layers, and I hope to make it fun for students, with a little bit of coaching.