Teaching half the class

Last semester, teaching was on average about halfway back to normal, but for computing it was almost normal, apart from the masks, which weren’t a big deal. I think it went well. I introduced a little warm-up introductory informal lecture at the beginning. This was maybe 10 to at most 30 minutes in the computing lab, introducing and motivating that week’s Python Jupter notebook. Students voted with their feet and despite it being at 9 am attendance was good. I will do it again next year.

But by good attendance I mean about 50%. This is higher than in pre-COVID times when it was taught in almost the same way, but without the lecture. It is also of course means half the class weren’t there, learning and getting help. The half that were there were clearly learning, the demonstrator (who was great) and I were fixing problems and clearing up misunderstandings at a good rate throughout the two hours of the computing lab.

Judging by the assessed coursework I marked, many (but not all) of those missing from the class would have benefited a lot from attending. It is frustrating to give feedback on coursework right at the end of the course, when that coursework really shows the student has unfortunately learnt relatively little. It is then too late to correct this at the time, so you are relying on the student deciding to change their ways and turn up and get help next semester.

Every student is different, both those who attended and those who did not, so it is hard to generalise. We have some good programmers who don’t like 9 am starts, and fair enough they can easily get away with not attending. I would argue they could still learn more if they attended, but I am teaching adults who make their own decisions.

We also have some poor programmers who did not attend, but again I think they are heterogeneous. Some lack confidence and for varied reasons, in practice deal with this by avoiding the problem. I genuinely don’t know what to do here. A few students just avoid problems as these problems get worse and worse, and they don’t act on our polite indications that this is not working. We introduced tests every other week to provide continuous feedback on progress, and to try and keep all students working steadily, but this is at most mitigates the problem a bit.

Other students may have already decided that their future will not contain much programming. They intend to, and do, pass this part of the course, but decide the 9 am starts are not worth it. I am teaching adults, so that is their right.

But others seem to be clear victims of the Dunning-Kruger effect. This is the, well documented and general, effect where someone who has poor skills also does not realise how poor these skills are. The classic example is that bad drivers usually think they are average drivers. Unfortunately this also applies to many (but again not all) poor programmers, who think they know what they are doing, when they really don’t. Some students with this problem don’t turn up to get feedback, and so see where they are going wrong. Weeks go by with them thinking they are doing OK when they are not. If they are working pretty hard but outside the lessons, then this is a bit of a tragedy.

In some cases they only realise this after the feedback late in the course. I always encourage students who read their feedback but still don’t understand what they did wrong to ask me for help. A number do. The emails from students are mostly one of two types:

1. The student is 95% right but has one error. I have been teaching computing for over 20 years, and each year students still come up with new ways to get the wrong answer. If you have not taught computing, please trust me, you would not believe how many different ways there are write five lines of code that are almost right, but give you the wrong answer. These emails are a pleasure to answer. First a bit of detective work to find the error, then tell the student what the problem was. They typically see it immediately, and I think learn not to do it next time. This is a good learning experience.
2. The code of the student is at least 50% wrong but they think it is about 20% wrong. This is the Dunning-Kruger problem, and it is awkward. You are then the bearer of bad news. You just have to be constructive, by suggesting that next time the student runs the code by an academic or demonstrator before submission, so problems can be picked up there. But I worry that in many cases this is not the first time the student has made this mistake, despite receiving feedback that says their code had problems.

The Dunning-Kruger problem is hard to deal with in teaching a class, because not everyone who lacks skills is unaware of it. Many are all too aware of it, and lack confidence. What if of the students not attending, 10 have the Dunning-Kruger problem, while 10 lack confidence? As they are not attending, I don’t know which is which, and both types don’t learn as much as they could. In contrast, for the ones who turn up, it is easy to see what the problem is and talk the student through it in the best way.