Next semester, which starts in less than two months (well, much closer to one month, but I don’t want to think in those terms), I am teaching an Introduction to Programming class that is aimed at freshmen engineers. It is a required class. It is a big class. It is a class that will have students who have been programming for many years already, and students who have never looked at a line of code in their life. I am scared.
I have taught two large classes before, but those were not mandatory, and the topics were more fluid, so I could throw in some interesting things to keep the class entertained. That really allows the class to be much easier to teach, since the students are engaged. With a fixed topic, especially one in which there are three sections that all need to teach the same thing (but by three different professors), it becomes more challenging to engage the students. There are therefore two large problems that I see, setting aside the actual main content of the class: (1) how to engage the students so that they desire to come to class and pay more attention; and (2) how to teach in a way that everyone gets something out of the class.
Some people may argue that it is not our jobs to “entertain” students. I would counter argue that it is our job to maximize the educational experience of our students. How can we convey information in a way that maximizes learning? I think that that topic might be too big to discuss in this blog post. But, let’s pretend that a good way is through entertainment and making the class interesting.
I heard a rumor that one of the professors who has taught this class before discusses interesting technology news items each week, which is a good idea. Another thought is to have some in class activities.
In programming, debugging is one of the key skills that is never really taught. Most programming classes that I have ever taken concentrate on teaching students the syntax and the algorithms, instead of the debugging skills. I am not entirely certain why this is the case, except that debugging often unique in every situation. You have to look at the code and figure out what is wrong. This is very dependent on the code. Except, it is not. There are methods that you can use to debug. Everyone who programs has some sort of method for debugging. I am sure that the skills are not universal, just like coding styles are not universal. But, there are some pretty good tricks to debugging.
I have therefore thought that one way to throw interesting things into class would be to teach debugging instead of just programming. I would do this by putting up a code that has a few bugs in it and have the class try to figure out where the bugs are. We would talk about how to go about doing this. The codes could be uploaded, so that the students can download the codes and try to debug them in small groups. I would like to do this every day, allowing them to get into the habit of debugging.
Another idea that I have is to make a math or physics problem and give them 20 minutes in class to work in teams to come up with a solution. They would have to quickly program something and report the answer. These programs would have to be extremely short, and would have to somehow stress what we are learning in class that day. Or, the programs could build on each other from week to week, growing in complexity. The problem with this is that if the students don’t get the last code to work, then they get behind.
Another idea that I have for class is to have the students actually create outlines for their codes. They could draw a block diagram that shows the different sections of their codes and how they interact. Then, the could develop the code according to their outline and/or block diagram. The reason that I suggest this is that most students that I have interacted with tend to try to accomplish the entire task in one sweep. The way that I program is to write (and test) little chunks of the code at a time. Then I either write a second chunk and incorporate it, or add more on to the first chunk, increasing the complexity as I go. When you follow the strategy of adding a little at a time, it is easier to debug.
The creation of outlines or block diagrams could be done in class also. While students who have absolutely no experience in coding will gain a lot from these exercises, the more advanced students might not appreciate them as much, since they will probably argue that they can see how to do the (simple) code, so the exercise is a waste of time.
This whole class will end up being a lot like writing a complex piece of code – try a little bit, debug, try a bit more, debug, optimize, debug, cry, debug, optimize, finish. Should be interesting.