Protactinium: Review, week 1

So I didn't end up writing the review on the same day, as I had planned. On the bright side, I was able to take notes during the tutorial, so there is a lot that I can reference.

Some of my notes don't make sense to me, because I took them quickly. I should reread the notes directly after the tutorial, to keep my memory of them active.




--------------------------------

- I expected people to missing or late - for this was the first tutorial and people would have difficulty finding the rooms. People were missing, of course. I suppose not everyone had been notified that there was a tutorial in week 1. It's not very standard for a course.

In fact, the late one was myself, and the students were waiting outside the class when I arrived ten minutes after the start time. A terrible underestimation of the bus queues for the first week of university, a mistake I will not repeat. Next week I will make my waking time at least one hour earlier.


- The advantage of holding a tutorial in week 1, before anything else happens, is that you get an extra week of tutorials. Additionally, you can guarantee that your tutorial is the first exposure first years have to computing. They get exposure to your tutorial before anyone else's, and enjoy it, leaving a positive feeling in their minds towards tutorials.

All in all, I feel like the advantages afforded by holding a tutorial in week 1 is not worth it. The lack of attendance is painful, the lack of preparation time on my part is painful, and the confusion caused to the students is somewhat avoidable. Surely the lecturer has some alternative advantage in mind when deciding to unconventionally hold a tutorial in the first week.


- I did not take notes during the first hour. Ideally the tutor should avoid phone usage as much as possible - phones are seen as a form of entertainment nowadays, and a distracted tutor does not leave a good impression on the students. I took what notes I could during the lab, by quickly whipping out my phone, writing the note, putting it back, and then continuing walking around. In the lab, they will probably be looking at their screens most of the time, so it is unlikely that they would feel like I am not paying attention to them. Additionally, none of them had to wait very long for my assistance.

Better would be to take notes on a laptop, because that has the semblance of doing work, but it is not much of an improvement and it does not outweigh the inconvenience of carrying a laptop around. I think I will survive as long as I pull out my phone at the correct times.


- The tutorial began with the name game. Basically, you introduce yourself, and then recite the names of the people who have previously introduced themselves. This has two main advantages: people are forced to familiarise themselves with other people, and people will be concentrating on remembering other's names rather than how they present themselves. It's an interesting concept.

In the compass course, we use a different variation on the name game - we integrate it with the 'print' command. They write a program that prints an introduction to themselves in the terminal, then they pipe it to Mac OS's 'say' command to get their computer to introduce themselves on the inbuilt speakers. It's a far more well-integrated concept - perhaps we could integrate it into the lab somehow.


- I think in general it's always a good thing to make sure the knowledge taught is connected to each other - connections is how learning works. Making sure that your teaching are well-integrated with each other has multiple benefits - you revise previous content while simultaneously learning new content, new content has an existing knowledge base to build itself upon, knowledge is easier to remember since there are more overall connections. This is being didactically effective.

There is also another point, which is integrating the knowledge in your course with common knowledge that the students have. For example, when teaching conditional statements, you could use a real-life example. "When the teacher is within 4m of the sensor, turn the light red so you know to hide your laptop. When the teacher is further than 4m of the sensor, turn the light green so you can pull out your laptop and continue working." If you can construct an example that is engaging and has real-life applications, the students have a platform to build their knowledge upon. This is building foundations.

This also has another purpose - effective schematic categorisation. If the material is well-linked to existing knowledge, the students consider it as relevant and useful then it provides another addition benefit. When the student sees something outside the course (for example, a door authentication system), they will recall the practical example of software in the tutorial, and start thinking about how the conditional statement could work in the door authentication system (if user_authenticated:). This is a form of active, unintentional revision where the student has a chance to create more mental links, reinforce existing mental links, and build upon knowledge outside the classroom.

The alternative is ineffective schematic categorisation, where not enough real-life examples are provided, and thus all the information learned during the class would be placed in the "Information retained in order to perform well in exams" schema. There is very little revision and reinforcement outside the classroom, and the student has problems recalling the information taught.

The protactinium course is much more constrained than the compass course (the icecold course even more so). 1 hour of tutorial, followed by 2 hours of lab. I think it is reasonable to say that attempting to change this would cause more trouble than the value it is worth. It is far easier to design my lessons around this structure, and see how far I can get from there.


- Since I did not have time to adapt my own content plans for this tutorial, I simply took what I could remember from the lecturer's notes. The abstraction exercise, the cake-recipe exercise, and the microprocessor demonstration. Since my laptop hadn't been working, I was forced to skip the microprocessor demonstration in the end.


- The abstraction exercise went well, I think. I stood up the front and gave a brief summary of abstraction, and then I gave my own example of abstraction (i.e. a human). I think giving my own example of abstraction was essential - I am a strong proponent of teaching by example. If I had not done that, the students would have felt pressured and inadequate, because they might be unsure of what an example of abstraction was. On the negative side

The abstraction exercise was also done in pairs - the lecturer is very ambitious with this exercise, I'm thinking, as I watch the students talk amongst themselves. He is attempting to simultaneously help them understand the principles of abstraction, doing it in a constructivist fashion (By getting them to come up with their own examples, they must first have a solid mental model of what abstraction is), and building teamwork at the same time. This activity is actually really solid. But on the other hand, teaching abstraction so early in the course may not seem relevant to them. They will not quite understand why it's useful, why they need it, until their programs become larger and much less manageable.

I tried to extend the activity a bit longer by challenging the finished students to see how many layers of abstraction they could come up with. A solid idea. Eventually I stopped the students when I sense they have exhausted the activity, and one or two people were chatting idly about each other. Which is not a bad thing at all! By getting to know the other students as people, they are building a sense of teamwork and community. However, if this continues for too long, they will feel as if they are not learning anything in the tutorial, and I will lose my presence. While I do not seek to be their commander, or their leader, I do seek to be their guide, and they will not trust me to guide them unless I am respected and I have a well-defined position in the tutorial room.


- Then I moved on to the concept of specificity. Since I was unable to obtain the exact recipe beforehand, I transcribed what I could recall from memory. The students found it easy to engage with the activity, although I'm unsure whether they found it interesting or relevant.

Nearing the end of the tutorial, I wrote down the three main concepts for the tutorial+lab on the board. Abstraction, Specificity, and Microprocessors.


- My main concern with the tutorial was that I was unable to cover anything concrete in the tutorial: since I was not quick-thinking enough to get my laptop working, I was not able to provide the practical, real-life link that I illustrated earlier in the tutorial. The specificity example with the cake was fairly fanciful, and I'm not sure that they were able to link it to reality. I could only try to give some examples where it might be useful, but verbal examples are of little effect.

This was mitigated somewhat by the fact that the activities were interactive and they had a chance to construct their own knowledge. Well done, lecturer.


- During the lab, I got them started on the online activities. Some of them breezed through it. Pi Guy, in particular, got started on the difficult bonus activities, and with some help, made decent progress on them. He seems to enjoy challenges a lot, and seeks to prove his worth by completing them.


- Others were fairly behind. In particular, there was a bug getting the microprocessor emulator to work in the default browser (iceweasel) so I had to manually start up Chrome for some of them. If I had known to prepare for this earlier, I would have demonstrated an example, and left it on the various projector screens for anyone to see.

Friction in lessons (where learning does not occur, and instead we are dealing with technical difficulties) is unpleasant, and leaves an unpleasant experience of the lesson.

There is some necessary friction (e.g. learning how to debug programs, etc. There is also unnecessary friction that the students learn nothing from (e.g. figuring out why the activity wasn't working in Firefox.)


- As I did not get my laptop working in the tutorial, I was not able to provide an overview of Linux. Luckily, the lab activities this week were most microprocessor activities, etc, so they did not need to use the terminal at all and could mostly ignore it.

Optimally, the terminal shouldn't open by default on startup. You want to minimise irrelevant visual artifacts when learning a new and complex system.


- I was not able to provide an overview of microprocessors in the tutorial, either, for the same reason. Huge mistake. I had lots of students asking me questions about microprocessors, which is not a great things.

If a student is unwilling to ask questions, that is a terrible thing. They will get stuck on something, not ask for help, and feel bad because they wasted a lot of time on something that could have been simple.

However, if a students needs to ask too many questions, that is similarly terrible. They feel bad because they are wasting the tutor's time, and they feel bad because they are asking more questions than other students and feel that they are doing badly.

If only I had covered microprocessors.


- They were working in pairs. In this tutorial, however, only a few of them chose to work together. Others sat by themselves. There were two pairs that I particularly liked, because they checked on what each other were doing and helped each other do tasks. However, I feel like the icebreaker did not break the ice that well. I need something that truly breaks down the barriers between people and makes them accessible to each other.

Future note: Pairs did not work perfectly in this lab, but this did improve in the future.


- Next tutorial, it would be good to add a context (real-life links) to the microprocessor work. This way, they understand where the microprocessors are found in real examples and why they are needed. Contextual links, real-life examples, etc.

The microprocessor work is actually fairly interactive and fun. I like it! It's something that students get to experiment on, see their results in real time, and provides an introduction into problem solving and devising your own solutions to problems.

I feel like the microprocessors is a solid introduction to the course - jumping straight into C is not the best idea. Well done, lecturer.


- Gave people lollies at half time. I feel like this is merely a 'fun-promoting-tool' - essentially something that makes the tutorial seem more relaxed, makes it seem more like I care, and makes it seem like the tutorial is informal and enjoyable.

Maybe the sugar high helps as well? lol. Makes people more excitable, more likely to talk to others, more friendly and optimistic. Something to consider in future.

Or maybe not. This is starting to sound suspiciously like drugging students for the sake of education.


- I have the Pi Guy some good questions to think about. He was doing a challenge question, and he wanted to know what a perfect score on that question would be. I asked him a few questions for him to think about, and that helped him improve his score. His submission wasn't perfect, though. It won't be until much later in the course.

Pi Guy ended up helping two other students in the class. I think that's a good thing. Student's usually aren't as good as me at explanations and stuff, but the advantage is that they are much more accessible. Students are much more likely to ask other students for help than the course tutor, in my experience. I'm not sure how effective Pi Guy was, but it's definitely a good start.

The Teamwork idea for the portfolio was also a great one. I'm wondering how much thought the lecturer must have put into the course, because the materials certainly are impressive.


- Overall, I had less attendance. After the second tutorial, I realised this was because people didn't have the week 1 tutorial in their timetable. I suppose it was ok to cover the less foundational content like unix and C, because then it won't be repetitive when I cover it in the next tutorial.

If I had covered unix and C in the first tutorial, I would be left with the unpleasant choice of covering repeat material (which would be boring for the people who had already done it), covering repeat material in greater depth (which would be confusing to the people who hadn't done it), or not covering it at all (leaving the people who hadn't done it on their own).


- The toast estimation exercise is an example of breaking down an abstract problem into something more defined. I feel like it would be a good idea to go over some examples of breaking down abstract problems, because they would not have encountered them before.


- The online site went down due to server load problems. Horrible, but there's not much I can do besides remind the site administrators that the site is going down (which I'm sure they know well enough already). I should prepare some backup ideas in case the site does go down again (for example, some cool interactive exercises).

Backup ideas:
- Come up with some C exercise and put it on the whiteboard/projector. Get them to do it in pairs
- Give them some cool logic puzzles. Pick one easily diagrammed and draw if possible
- Team-building exercise. Team logo exercise, egg drop exercise.


- Knight came in late to the lab. He wasn't quite sure what was going on, and I told him to login to a computer and have a go at the work. My mistake was not sitting down with him long enough, since he was confused on what he was meant to be doing. Of course you would be confused your first time going to a lab. I simply assumed he would be able to pick everything up on his own. Huge mistake.

During the lab, he asked me what was going on. Which was actually the saving grace here. If he hadn't done that, he might have been screwed for the entirety of the course.

He seemed mildly resentful of something during the tutorial. He seems to be generally...irritated? Annoyed? I don't know how to describe it. He probably hasn't had a very good experience with educators in the past, and I will endeavour to make his learning experience enjoyable (as I try to do with everyone, I suppose).


- Green asks no questions, and prefers to work by herself. She writes lots of notes, and appears very serious. I'm not sure what to do about this. On one hand, interacting with other people is good, as it improves your learning experience and makes it more enjoyable. On the other hand, if someone is just not interacting, because that is the way they prefer to learn, then who am I to stop them?


- I forgot to mention that the lab exercises should be done in pairs. In retrospect, this may have not been a good thing. Forcing people to be in pairs causes friction, and I do accept that, but the friction may be a necessary sacrifice to have a smooth and friendly tutorial by the middle of the semester.


- The microprocessor emulator contains a lot of unnecessary information. For example, the instruction pointer, the instruction store, and the swap register. I'm not sure all of this is absolutely necessary to learn the microprocessor, because it does make the exercise a bit more confusing, but I suppose it does make it more realistic and makes it a bit more interesting for the more advanced students. I can't criticise much about this.

Really, there's very little I can criticise about the course design in general. I'm somewhat surprised.

Something I have to keep in mind is that protactinium is the more 'advanced' stream for the course - it's taken by people who believe in their computing ability, people who truly want to learn more about computing. People who want to learn about computing enough that they take an extra computing subject.

All engineering subjects (except computing major) are given the choice between icecold (the less advanced stream) and protactinium (the more advanced stream). The people who pick protactinium must have some genuine interest in computing. Conversely, the people who pick icecold are either unconfident in their ability, or prefer an easier course (marks, less effort, etc). I should definitely keep this in mind - I can take more risks with advanced content for protactinium, and the students will probably be interested. I'll still do my best to teach the crap out of both courses, though.


- I notice that basically all the students in the class are cheerful, except for the late guy (Knight) and the quiet girl (Green).


- The first impression, in summary, perhaps was not done as well as it could have been. But I suppose the first impression is not the end of the story. The tone is set not merely by the very first class (although the very first class is the most important one), and I have a chance to redeem myself in the following classes.


Tutorial additions for the future:
- Highlight reel
- Cool demonstrations of readable programs
- Briefly revise first week's content for missing people. 9am - there will be so, so many missing people
- Link microprocessor work.
- Explicitly mention pair programming
- Breaking down abstract problems realistic example from work