Ultimately her teaching experiences have caused her to ask “do the students really have a solid understanding of the mathematics they are using?  And, more importantly, do they understand why they’re using it?”

I think you know where I’m going with this.  Too often in computer science courses (and in fact in other IT courses that are offered in high school and I dare say in post-secondary) are planned so that a certain amount of material is “covered”.  Students get to practice modifying and writing code but often have no clue why they are writing this code.  They get to memorize some syntax but don’t understand what they’re memorizing.  There’s little of no context within which their work in writing code can be placed.  One might call this “context-free content”.  I think the author of the article is saying the same thing, but for mathematics.

Another way to look at this is to relate it to G. Polya’s four-step problem solving approach:

• Understand the problem
• Design a solution
• Solve the problem
• Assess your solution

Too often particularly in my early years of teaching computer science, I would “understand” the problem for them (put it in simplistic terms, over-simplifying), then with them I would “design” a solution (though even these simplistic problems might have had several approaches, we ended up with one).  They’d “solve” the problem (of course the detailed design encouraged almost identical solutions) and I would develop the test cases to see if their program “worked.”

There is little ownership by the students, little opportunity for real insight into any of these steps, little reason to learn and understand the programming techniques  beyond the next test.

I know I had to work hard to get  my students to expand their involvement beyond coding something that either we or I had understood, designed and assessed.  It wasn’t always easy but helping students find a context for their work with more realistic problems and situations always paid off with students being able to apply what they learned later in the course and more importantly in later courses.  Open-ended problems  helps out a lot.

Think about helping students understand the “why” along with the “how” of computer programming, especially when you’re given a course and a text to “cover” with a group of students.

Find a context for the content.

(full URL for the article:  http://www.edweek.org/ew/articles/2013/03/27/26crowley.h32.html?tkn=LNSFw%2FMoqekT4IEeYBSFfusZ4rOHVCeJYo%2F0&cmp=ENL-EU-VIEWS1 )

And chocolate, inevitably, reminds me of how hard it can be to conduct education research.

A few years back, I submitted a paper to SIGCSE and one of the comments I received back from a reviewer has stuck with me ever since. I’ve completely forgotten the details of the paper, but it presented some kind of teaching approach that could be used in the classroom. I had collected student survey data and reported that students enjoyed the experience. The reviewer dismissed the evaluation as largely irrelevant and stated: “If I gave out chocolate in my class then students would enjoy that too!”

Enjoyment is an important consideration, since the more that students enjoy something, the more likely they are to actually do it! But what they *do* has to be shown to be beneficial.

The more time that passes since I received that comment, the more I value it. With the perspective of distance, I’ve even come to use it as a yard-stick to measure my own research and that of others. Sure students enjoyed it – but is there evidence of some deeper and more significant benefit, or is it just chocolate? Students enjoy chocolate, but it isn’t a healthy option – too much of a good thing leaves no room for vegetables. What evidence do we have that the learning activity / software tool actually helps learning?

I recently pitched an experiment to a colleague of mine. I suggested that we could show that chocolate helped people learn how to program. In our classes, we have a big attendance problem, with less than 50% of students attending most of the time. I suggested that a free chocolate bar to each person might be sufficient motivation to get them into the class. If indeed, the chocolate was enough of a motivator to attend, and if lectures actually help students learn anything, then the class average might be higher than in previous years. In other words, offering students chocolate might produce a significant improvement in learning – perhaps a greater positive impact on learning than anything else I’ve tried recently. Unfortunately, getting the project funded is proving difficult.

I see a lot of papers that show how much student enjoy a given approach / tool. Some of them even show how it improves learning. They always make me think of chocolate.

Andrew

The responses led me to think about my attitude toward failure.  While it can be discouraging and disheartening to fail at something, it’s also inevitable.  It is only the most gifted of people who doesn’t experience failure on a regular basis, and those who push themselves experience it more often.  Personally, I see failure as feedback.  It’s a sign that you were doing wasn’t quite right and that you need to try something different.  The only part of failure that reflects on me as a person is my reaction to it.

Since this experience had come about in a work context, I also thought about failure and computing.  It occurred to me that my attitude about failure is particularly helpful in someone who wants to work in a computing-related field.  Problem solving, and the inevitable failure associated with it, is core to computing.  People who are successful in computing are people who handle failure on a regular basis: the program crashes, the network goes down, the algorithm has a problem, the machine dies.  Handling these situations requires a certain acceptance of failure as a natural part of the process.

But my experience teaching has let me see that students don’t tend to develop this attitude about failure until at least midway through their programs.  Students in early classes, typically programming classes, often personalize failure in ways that may not be helpful.  Yes, a student who repeatedly fails at coding probably isn’t going to be a developer, but some amount of failure is part of the process of coding and therefore part of the process of learning to code.  When I teaching CS1/2 I try to convey that failure is natural, as a way of letting the students see that they shouldn’t take their failure personally.  I’m not sure how effective I am at this.

Speaking of effectiveness, all of this led me to consider what the literature has to say about failure and computing education.  In my search I ran across two interesting articles.  In the first, Tony Clear writes about failure in the context of a capstone course, which is a situation on the opposite end of a degree program from CS1/2.  In the second, Klara Benda, Amy Bruckman, and Mark Guzdial examine failure in online courses.  There failure means lack of retention, and I particularly enjoyed their summary of the literature on retention.  It also surprised me how few articles in computing education were displayed in the ACM Digital Library when the keyword failure is provided.  It was a much more common term in the broader computing literature, which is somewhat ironic.