Mailund on the Internet

Next term, I am teaching a class called applied programming, which is just a fancy title for script programming.

I finally got out of teaching programming a year or so ago.  I don’t really like to teach this topic.  I love programming, but I find it very hard to teach.  It is something you only learn by doing, and the typical university setup here is lectures.  That simply doesn’t work with programming classes. Period.

Anyway, the university has started a new bachelors program — molecular medicine — and they need to learn a lot of bioinformatics.  For that, they need some basic programming, and I have to teach them that together with Søren Besenbacher.

Teaching programming

In some sense, all skills you learn, you learn by “doing”.  Even if what you are doing is just thinking about it.

Asking students “to think about it” is not the way to go, though.  Trust me on that.

You need some techniques to start thinking.  If you discuss a topic with your friends — construct arguments for your case — you are forced to think about the topic.  If you have to present a topic to your class, you are forced to think about the topic.

When you teach a topic, you are really forced to think about it.

Programming, you really have to think about. You cannot fool the computer.  If you don’t know how to solve a problem, there is no bullshitting the computer into believing that you can.

So in a sense, it should be easy to teach programming. Give people a problem and let them solve it.  There is no cheating, and as long as the problem highlights the points you wish to teach, the students will learn it.

Why do I still find it hard to teach programming then?

Lecturing on programming

One problem is the way we typically teach here.  Teaching is very much based on lecturing followed by practical exercises with TAs.

It is mostly a practical matter. For practical exercises, you need small groups, and we would spend all our time on teaching if we had to do all the exercises ourselves.  Thus the TAs.  But you cannot leave the entire class to TAs and small groups, so we have the lectures to cover the broad topics and make sure that all the groups are keeping up with the teaching plan.

In many classes, this setup works fine, but I don’t think it helps much to lecture on programming.  The lectures in such a class can easily end up being a waste of time.

I can show you all the language constructs of Python on a PowerPoint slide, but that alone does nothing for teaching you how to use them.  It is absolutely worthless if you need to solve a problem using Python.

With 50+ students, I’m probably stuck with the lectures, but how do you structure lectures so you actually teach something useful for programming?

Teaching problem solving

Programming is, more than anything else, problem solving. So how do you teach people how to solve problems?  You show them how you do it yourself!

This is where it gets tricky, I think.  You are not showing people how you solve problems by writing down the problem and then the solution.  You need to show them how you think when you are making your way from problem to solution.  And you need to do it very slowly!

When you are experienced, you make leaps of intuition when you solve a problem.  You recognize something you have solved before and — probably without thinking about it — you immediately think of a solution that worked before.  It is very hard to avoid this.

You need to slow down when solving the problems.  You don’t want to dumb down, though!  You need to solve the problem without your experience, not without your wits. The students are less experienced, they are not stupid, and you won’t keep them interested if you are thinking slower than they are.

Ideally, you want the solutions you come up with this way to be the same you would come up with if you were using all your experience.  I personally hate it when text books come up with solutions you would never see in the real world, just because they haven’t introduced all the techniques you need to get the “right” solution; only enough to actually solve the problem, but in a roundabout and non-idiomatic way.

To avoid this, you need to come up with problems that not only can be solved with the techniques seen so far, but where the ideal solution only uses those techniques. I’m still trying to figure out how to do this…

Anyway, these are the ideas I am throwing around right now for how to approach lecturing on programming again.

Refusing to help (or “give them what they need, not what they want”)

So show you show the students how to solve a problem, and then you give them some problems to solve themselves.  This is where the TAs come into play.  The idea is that the students try to solve the problems themselves or in small groups, and then can meet with the other students in larger groups, maybe 15-20 people, together with a TA to discuss problems and solutions.

For small classes, I’ve been doing both the lecturing and the solution discussions.  My experiences here are not so pleasant.

First of all, it is very hard to get the students to actually try to solve the problems.  Not the computer scientists. In the previous script programming classes there were always a few computer scientists.  Those are already interested in programming and, to be fair, already know how to do it.  The non-computer science students rarely made an effort.

There is, of course, a major difference in being interested in programming and in considering programming a necessary tool for some other problem that is the real problem.

So there is a bigger problem in motivating the problems, but I don’t think that is the full story.

Once the students figure out that they can just show up at the meetings with the TA and then the TA will show them how to solve the problems they got stuck on, they will simply stop trying to solve anything themselves.  At the first sign of trouble, they just stop.  They do not try to work around the problems, or try to figure out why there is a problem in the first place.

This is probably the worst thing they can possibly do.  Programming is all about solving a larger problem by working around a bit pile of smaller problems.  You get stuck all the time, and need to get yourself “unstuck”.  With experience you will do this faster and faster, and often manage to avoid a lot of the small problems in the first place, but you need to get this experience by actually solving the small problems.

When people ask me how I would solve a given problem, I tend to tell them.  This makes me the worst TA ever in a situation like this.  I have tried and tried, with more success the older I’m getting, not to help too much.

It is essential that you don’t help a student who could actually solve the problem himself if he just worked a little harder and a little longer.  We learn from our own experience, not others.

What’s so special about programming in Bioinformatic?

What are we doing teaching programming anyway?

The Department of Computer Science teaches an introduction to programming class that is mandatory for half the student programs at the Faculty of Sciences.  So why do we have our own introductory programming class for bioinformatics (and related student programs)?

This is a good question, and there has been some debate over it. If only it wasn’t me who is supposed to teach the class, I would be a strong proponent for it ;)

Kidding aside, I do think there are strong arguments for having a different introductory programming class.

It is getting late, and I have a paper to read before going to bed, so I will leave  those arguments for another post, though.

Applied programming?

Well, I didn’t choose this title for the class.  I wanted script programming, but apparently that didn’t sound serious. Go figure.

Tags: programming, script programming, Teaching

This entry was posted on Tuesday, September 16th, 2008 at 7:44 pm and is filed under Teaching. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.