Tag: Teaching

From all the courses that I'm teaching this year, the one about Shell programming is certainly the one in which I have the worst difficulties to ensure that the students get the grip. I'm not quite sure what happens in here, and how to fix it actually. Here are my reflexions, and I'd love to hear your advice (for example per identi.ca, where I'm mquinson, or per email).

Some context first. At ESIAL, we teach shell at the end of the first year, from a three year long cursus. The goal is not to give the ability to use the shell, but rather to become fluent with the shell to the point where you can automatize some actions through shell scripts. Shell usage is not formally teached. We have 2 hours at the very beginning of the year on the topic, and it is expected that the students learn the rest by themselves during the year.

This constitutes only the half of a course, where the other part is about C programming. This is the first time that our students are exposed to the C language, and also the last time (beside of the courses in second year about operating systems). Together, the C and the Shell parts are somehow supposed to allow the students to master their Unix box.

But we do not find how to teach this module, actually, and as a result it is heavily lifted almost every years.

Before I arrived at ESIAL (2005), the pedagogy was very classical with several lectures, some repetitions and some labs. And it was a complete failure: the lectures mainly listed the reference of both systems (C and shell), and were only useful to the ones who already knew their content (maybe not even to those students). The repetitions were almost useless and contained too much material repeated from other courses, such as the ones on data structures.

So we decided to completely change the pedagogy to remove the lectures completely. Instead, we gave the lectures in small groups, just like it's done in college. Also, we mixed up the C side and the shell side, ie we sorted the content by complexity (easy C, then easy shell, then middle C and so on) instead of doing all the C and then all the shell (or the contrary). The conclusion was mitigated. The main issue was that lecture groups quickly diverged, even if we had a quite solid document to keep groups in sync. Also, the quality of the lectures were very different between the groups made by permanent teachers and groups made by TA.

So, 2 years ago, we introduced one classical lecture in C for the introduction to the topic, and we sorted the C from the shell. It was a bit better, but didn't really solve the lack of synchronization between groups. That is why this year we moved back to the classical lecture+repetition+lab organization. The main difference with 2005 is that now I know how to teach it: since the students already master Java quite well, I emphasis only the differences between C and Java. That way, there is no repetition between this module and other ones such as introduction to programming or data structures. See the result here: CSH.

I'm quite happy with the result for the C, and I think that this will make easier in the future to teach the system to these students, as they kinda understood the C logic (at least, I hope). Remain the difficulty of teaching the shell. Here, I'm puzzled. From the questions I get during the labs (there is no repetition in shell), there is at least two things that they failed to understand.

The first one is the general logic of the shell, how I combine small bricks to build a complex command (either by chaining pipes or with a for loop). In fact, I often have the feeling that they don't understand what they are writing at all. I feel that giving them a graphical mental representation of what's going on would help them. I'm thinking of something like the following.

The best would be an interactive animation, something close to a PLM world allowing to interpret the shell commands. Unfortunately, that would require an insane amount of work to get something usable. Allowing interactive commands and reproducible exercises in shell would be doable through virtual machines (with quite some work), but building the interactive visualization out of it seems almost impossible to me.

Instead, I'm playing with the idea of coming up with several animations showing what happens in a complex command so that the students can build this graphical representation. Will see how it works out.

The second thing missing to my students (I guess) is how to get the information they need by themselves. We have a very directive style of teaching at ESIAL and they are used to get all they need from the lectures. But this is just impossible in shell: we won't present all the options of each command that would be an incredible waste of time. It may be possible to fix this by providing the students with some screencasts of how I build the command myself: I have a very bad memory and always check the exact options in the manpage and such.

Solving this lack of autonomy of my students for real seem more difficult to me since it may require to change the other teachings to a less directive style so that the students get used to search the infos they need by themselves. That would be a huge shift, and I'm not quite sure of how to do that, actually. Although I'm quite convinced that it would be a great help to them on the long term.