Changes to My In-Class Approaches

I have recently made some drastic changes in my classroom which I wish to document here for my own records:

1. I removed from the course schedule a listing of which topics would be taught when.  My main reason (other than I don't enjoy making them) is that I feel constrained by them.  When we need extra time on a topic in class, my guideline (which I make myself and am not forced to follow) urges me to push on.  I don't like that.  What I find most interesting, is unlike other teachers, I actually don't have to follow a guideline, as I am the only teacher teaching my program (which I created myself) and have (close to) total autonomy.  However, I still feel a desire to keep up with them which is absurd.  So, to alleviate that issue, I have done away with them.  Instead, I now post what reading the students are to do on the course website on a daily basis (based on how much we covered in class that day).
2. I have started providing time in class for students to work on their assignments and have instead assigned readings to be completed out of class.  This is to provide them with an opportunity to get assistance while working on their assignments which they can't do while working at home (most likely alone).  Of course, they could run into trouble with the reading, but I hope that they can record their questions and bring them into class the next day.  Whereas getting stuck on an assignment may be more debilitating to their self-confidence as they work towards becoming Coding Ninjas/Gurus.
3. I have reinstated late penalties.  I removed them ages ago as I don't like them (and still don't).  However, this lead to the majority of students submitting all their assignments at the last possible moment (which was after the final exam).  This meant they weren't finishing them prior to the exam to gain the experience, exposure, and feedback possible from working through the code.  It also meant we were unable to take up the assignments in class.  So, now I have created due dates and the policy that the assignment will be addressed in class the day that it is due and a maximum mark of 50% will be given for assignments submitted after that time.  I am still not happy about the late penalty but haven't formalized a better alternative yet.

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.