Tuesday, June 28, 2011

If I Didn't Jump to Conclusions, I Wouldn't Get Any Exercise ...

I've been pondering why my students neglect checking the simple possiblities when their programs stop working. They always seem to jump to the possibilities that are more elaborate and therefore less likely. I was pondering this when I had my own jump to big stuff moment *cue transistional wind chime back-in-time music*

I was driving in my vintage '98 Grand Am (I know jealous), when I heard a clunking sound from the back. So I turned off the radio to listen more closely, at which point I became distracted by my own deep thoughts. About 5 minutes later I realized I didn't have any music which made me distraught. So, I immediately starting playing with my radio assuming that it had died. I tweaked the volume, changed the station, changed to AM and back to FM (I know I still listen to the radio), and was about to bemoan the death of my radio when I recalled turning it off. With a sheepish triumph I pushed the ON button and was graced with soft melodies.

So, it would appear that jumping to the worst possible conclusions is something I am guilty of too. I am sure this is an identified bias that humans suffer from but can't for the life of me remember which one it is. Luckily the first step to absolving a problem is recognizing you have one (even if you can't remember the name of it, which I guess is another problem ...)

Teaching Programmers ... or Programming Teachers?

So, I've been struggling lately with deducing the best* way to teach computer programming. So far, I'm at a bit of a loss. From my exhaustively intensive Google searching, I have deduced that there is not much out there regarding teaching computer programming/science. It appears that either everyone already knows how to do it, or everyone assumes they know how to do it. Being as I've assumed that I don't know how to teach it, I'm up the proverbial creek without a paddle.

So that leaves me with the task of creating a paddle for this creek (and that is where the analogy ends before you throw me overboard **). I will begin by recounting my current approach to teaching CS and proceed from there:

1. I lead in class 'tutorial' sessions peppered with lectures. I try to keep the lecturing (i.e. directly disseminating information without the students programming) short to focus in on solving a coding problem together.

2. In terms of assessment, my courses have exams (1 if the course is under 3 weeks, 2 if longer) and projects (open ended, PBL style). I have recently started adding in assignments, which are coding problems that are laid out for the students.

3. My class runs for a 5 hour block, Monday to Friday (which is a lot of time to teach).

4. I've started adding in what I call 'Quick Checks' which are questions related to the theory of what we are covering, but unrelated to the problem we are solving (they are meant to help the students pull out the concepts being used to solve the problem).

Now that that is out of the way, here are my observations thus far:

1. It recently dawned on me that my approach of 'live-coding' is really no better than having the students copy copious amounts of notes from the board. I believed that since they were coding (and therefore doing) it was a good approach. However, I have been finding that the students are just copying the code down without applying much thought to the process. So, problem 1 is to find a way to rectify that while still covering problems that are interesting and applicable to what they will face in the job market.

2. The Quick Checks have shown me that the students have difficulty separating the logic of the solution from the scenario of the solution. I think that they see them as the same thing. This is of course highly detrimental to coding, as coding is problem solving which is the act of applying similar thinking to new problems. So problem 2 is finding a way to separate the ingredients from the recipe.

3. The open-ended projects (which are meant as a means to explore the topics covered in course and create items for their portfolio) tend to be highly derivative of the examples I do in class. I feel this reinforces my conclusion drawn in 2 that the students have difficulty separating the logic from the solution.

4. There is still a problem with the terminology we use (i.e. methods, functions, constructors, parameters versus arguments) as well as problems with writing proper syntax. Along the same thread, some students are still having trouble formatting their code neatly (which I am a huge advocate for). This makes it much harder to learn the more challenging problem solving skills as the they are still grappling with the language in which the solution is framed.

5. There is difficulty in remember what we have already completed on the current problem. This is challenging as we often try to reuse code to minimize the amount that needs to be written. However, if you don't recall what has already been done, it is difficult to reuse it or even move forward. I find this also translates into not knowing what the program should be doing when we test it.

In regards to solutions, unfortunately at this point I only have ideas. My biggest worry about implementing changes is my own bias that the changes are effective/ineffective. I need a metric to indicate if the students are actually benefiting. My thinking is something similar to the Physics based Force Concept Inventory, however I cannot find an equivalent one for CS. Since my courses are over so quickly and then we are changing topics/programming language it is difficult to use my exams as a means for assessment (although I have ideas along that thread).

So, at this point dear reader I leave you as puzzled as I am; hopeful that you are intrigued to find this solution (or at least awake). I will leave scribblings on my ideas to future posts.


* best is a fairly loose word to use here, I know ... tsk tsk

** that is the actually end of the analogy, the first was a blatant lie.