Icecold: Pre-course discussion

Soon the lecturer + TA meeting for icecold is coming up, and it's time to start thinking about how I will prepare my classes.




-----------

It is useful here to note the differences between icecold and protactinium, not only as an explanation for the reader, but also as a reminder to myself.

- icecold only covers half of the content that protactinium covers. However, in the first lecture, the lecturer stated something like "this is not an easier version of protactinium." and then something about "do not take this course as an alternative to gain higher marks".

-----------

We had a brief pre-course meeting to discuss how the course would be taught. Here are some points noted:

- The first lab has some bugs but they will be fixed later. I expect that this will be a common occurrence, because it will be unlikely the lecturer has time to proofread the labs before releasing them.

Problems with lab instructions are actually a major factor in how successful the course is running, because a difficult and stubborn lab question makes the whole experience of the lab negative. Luckily, the lecturer will give us access to the github repository containing the instructions for the lab, so we can rectify it somewhat.

The lecturer mentioned that there is plenty of room for improvement via github, so we should make the most of it where we can. I don't feel confident to make any large changes, for example, changing the structure of an entire lab exercise question - regardless of whether it is a good idea or not, I feel like the lecturer would disapprove of that. I suppose we shall see when we encounter the lab - we shall see if there are any major problems with it.

- This week's lecture notes will be missing. I think this will be a less common occurrence, and is of relatively minor importance. Usually, you can expect reading of lecture notes to be done only before tests, examinations, and (occasionally) before tutorials.

- The lecturer offered his phone number. Personally I do not see the value in asking for it - I cannot imagine an emergency where the lecturer could cope better than, say, the university's security department.

- Tutorials are non-compulsory. You will always have non-participating and shy students down the back, who prefer to avoid interaction. I think that the non-participating and struggling students are a tutor's highest priority. The more behind you are, the less effectively you learn (priority #1), and the more negatively you feel about the course (priority #2).

The question is, how do I deal with students who do not participate in tutorials? The first step, of course is to make the content accessible: to make sure that everyone is following along easily even if they are a bit behind.

 - Tutorials should not be mini-lectures, and the smaller group of the tutorial offers an opportunity for far more interactivity than a lecture offers. I've been thinking about this for a long time - more on this in the 'Effective tutorials' pedagogical post later.

- The lecturer suggests a method to help engage all students in the class and to make tutorials more interactive - that is, throwing a ball, or some object to some student to 'randomly' select them to answer the question. Personally, I am doubtful of the effectiveness of this method, but more on this in 'Effective tutorials' to come later.

- The lecturer welcomes suggestions for the course. This is a good sign - it means that any feedback from tutorials can be incorporated into the lectures and an overall superior learning experience can be provided.

I plan to make a weekly icecold digest and send it off to the lecturer. It will be a brief summary of my review and reflection - for no one has the time to read my tediously longwinded reflections.

- The lecturer has tried to make the automarker as friendly as possible. For example, commenting when a space is missing, or commenting when a newline is missing. This is great! Automarkers which do not offer good output are supremely difficult to defeat for even me.

- The lecturer uses a variation on the standard 'gcc' for compiling programs, and this variation contains a wrapper for better debugging output. For one, immensely useful for introductory students: the debugging output of C is notoriously difficult to understand for beginner programmers.

- Each week the only compulsory activity is a lab that has to be submitted to me. It has to be submitted via the automarker and also get manually marked off by me. This is a little inefficient and tedious, and it is not completely apparent what the intent is, but it is unlikely I will be able to enact any effective change in this respect.

I am in search of visible results and effective solutions, not theoretical pedagogy and meaningless debates.

- Keep everything positive and make sure you are always positive and encouraging of the students. The advice is good advice, but not particularly useful to me. I am starkly aware of the effects of positivity in the classroom, and already am trying to maintain my own positivity as best I can.

- In the first lab exercise, they will get errors, and we have to make sure they know that it's okay to get errors. I agree with this - it is exceedingly important that they get accustomed to errors. Labs aren't straightforward, and I have to come up with an ingenious method of showing them that errors are fine, and we have to solve them ourselves.

- Lecturer requested that the tutors don't 'slag off' the lecturer or the school. Generally I have not had a particularly high opinion of the lecturers I've tutored for, or the school, but hopefully that will change a bit with the coming semester.

Once I asked a lecturer, "What is the rationale behind the design of 1h tutorial + 2h labs?" I then asked, "How do you think I should most effectively use this time?" The reply was, "That's a good question. I don' t know. [laughs] I hadn't thought about that before."

- The target audience is comprised of mostly electrical engineers, as well as a mix of other engineers who don't major in computer science. They will be much less interested in the course content than protactinium students, who are either majoring in computing, or self-motivated and enthusiastic enough to pick a more difficult course.

- The first lab contains a task to email the TA and post on the course forum (Piazza) so that they are aware it is available and have an avenue for assistance if needed. I am glad the first lab includes this activity, for it is the very first lab, and they will definitely have the time for it. By attempting it for the first time, they are setting a strong prerequisite for seeking help the same way in the future.

At the moment, it may not be clear which avenue is best to seek help from. i.e. when you should be emailing your TA  as opposed to asking in Piazza. However, I think it is not a huge leap to intuitively understand that student questions about C, unix, the course, etc. should be answered in Piazza and questions like "hey what are we doing in our tutorial this week" and "hey you forgot to mark me off" should be directed to your TA.

- The lecturer mentioned that this week is essentially a no-op - i.e. the students basically get marked off for turning up, because the lab exercise is so easy. Sounds good to me, having a week for the users to familiarise themselves with the environment.

- The students will want feedback. Give them feedback on their coding style, etc. I'm not sure about this - I am doubtful that I will have the time to comment on their coding style, or that they will understand the benefits of coding style.

I think I will prefer to comment on coding style for more complex programs - for example, assignments. This way, it is easy to explain the benefits of coding with a particular style. They might forget the feedback, since it would be entirely verbal and has no persistance, but since I am commenting on their work, they will have some emotional attachment to it, and it will help assign a psychological sense of significance to my comments (thus making them pay a bit more attention and remember more).