A recent blog post by Mark Guzdial (Learning Computer Science is Different than Learning Other STEM Disciplines) has my mind going in a bunch of different directions between the post itself and the comments people are making in various places. I see a bunch of posts in my near future but I’m going to start with asking the question “How hard are the programming assignments we give students?” and “Do we really know?”
Mark Talks about the “Rainfall Problem” that started with Elliot Soloway. (I link to a couple of papers on the subject below)
Design a program called rainfall that consumes a list of numbers representing daily rainfall amounts as entered by a user. The list may contain the number -999 indicating the end of the data of interest. Produce the average of the non-negative values in the list up to the first -999 (if it shows up). There may be negative numbers other than -999 in the list.
If you are anything like me, your first assumption will be that it is easy. A piece of cake. Surely my students will solve that in no time. And yet the research shows that this is a very difficult problem for first year CS students. How can that be? I’m not sure we really know. Of course I will have to assign it to students first chance I get.
A famous interview question is FIzzBuzz.
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
Apparently that is a difficult problem for a lot of CS students as well (Why Can't Programmers.. Program? and Using FizzBuzz to find developers who grok coding) I assign that to my students and tell them in advance that is is hard. Most of them solve it pretty quickly. Am I a great teacher or do I have exceptional students or is something else at play here? Do we even know? Probably not.
In general I find it difficult to estimate how hard a programming project will be for beginning students. Let’s face it, I’ve been programming for 45 years so anything I am likely to come up with for first year CS students in high school is going to be pretty trivial for me to code. After assigning a project a couple of times one gets a sense of course but the variation between classes can be huge.
So if a problem takes too long or too short to complete who is to blame or credit?
Kathi Fisler from WPI said in a recent Facebook comment “From what I've read as I dig deeper into this, a huge factor in whether novices can solve _any_ programming problem is how closely it connects to problems and code patterns that they have seen before.”
That makes a lot of sense to me. DO my students do well with FizzBuzz because they have seen similar patterns in my class? Maybe because of the way my mind works and because of my experience both programming and teaching programming. If so, that raises a new concern. We can’t teach every possible pattern. We don’t even know every possible pattern. So how will our students do when they are exposed to something outside their experience?
My last set of questions, which I am struggling with today, are we teaching to the problem? In other words, do we teach in specific ways to prepare them for the problems we know we will assign? Is that good or bad? If bad, how do we do better? This teaching computer programming is hard!
Rainfall related academic papers
- Do We Know How Difficult the Rainfall Problem is?
- The recurring rainfall problem (Behind a paywall – sorry but if you really want a copy send me an email)
4 comments:
Other than programming I have taught Alg I thru pre-Calc, Senior Physics, Senior Stats, basic math at the college level thru college calc, and Math Methods for Elementary Teachers. Programming is by far the hardest to teach. (OK, the Math Methods ran a close second. Most of the room is filled with people becoming elementary teachers to avoid math.) Students cannot just memorize a formula and survive. They have to think in unique ways and problem solve. Being willing to problem solve is the big separator of students. I look at those two problems and think "No bid deal". I have a few years of breaking problems down into pieces, the kids do not. They see the problem as this big thing. We see the problem as a bunch of little things that just require assembly.
Getting students to see a big problem as a set of small things that need to be put together is a great way of putting it. It seems to be hard for some.
Also the wording of programming problems is a barrier. " ..consumes a list of numbers.. " and "Produce the average..". I see a lot of programming problems worded in a esoteric or odd way.
Rephrasing it, "You are going to calculate the average of a list of numbers entered by a user. The list of numbers could be either positive or negative. Include only the positive numbers in your calculation. When the user enters -999, calculate and display the average."
Just a thought.
I was thinking about the wording myself. Sometimes it seems as if the wording is a puzzle and not a clear statement of what is wanted.
Post a Comment