The planning section is a great memory aid and reflection tool, because I can compare what I was thinking before the class to what I was thinking after the class. Let's bring it up.
---------------------------
- The first session of any class is a difficult one to plan, unless you have a lot of experience with first sessions of classes. This is because you have nothing to work off - you don't know what the class is like (you can only guess), and you don't know what problems the class is having. You can only hold generic, broad activities that hopefully will work for a wide variety of students.
Tutorial
- I don't recall what my introduction was like, but I feel like it wasn't energetic or enthusiastic enough. The instructor of a class dictates the mood in the class, and the mood of the class was not particularly exciting.A few weeks ago, I participated in a day-long speech skills seminar, and at the end we were asked to prepare a final speech at the end which incorporated all the skills we had learned throughout the seminar. My speech was a 'Welcome to Computing!'-type speech, where I tried to inspire students and motivate them prior to the start of the course. I think I planned and executed it fairly well.
If I combine the introductory speech with cool demonstrations of programs written in C, I can make a fairly strong and effective starting point. The demonstrations would absolutely need to be in C, so that I can show the students, "hey, I'm using the same tool as you, and making awesome stuff with it!".
In the actual class though, I wasn't able to prepare the demonstrations in time, so I just did the same short inspirational speech I did in compass (different from the speech seminar speech). I can't be sure whether it had any effect, because the class did not seem particularly enthused by it. I feel like it worked better with the high school students, though I'm not quite sure why.
- After my mini-speech, I got them to talk to and introduce the person next to them. My suspicion was that some people would have come into the class with no friends, and it would be great for them to get to know the people around them. It's just better if you have a friend in the class, because it feels more positive.
As with many strategies, this one worked well with some people and not well with other people. The more friendly people got to know each other and sat near each other, and asked each other questions. The less social people chose to sit by themselves, which I suppose is unavoidable. The cost of trying to improve the social experience of unsocial people is too high for me to consider.
- I briefly showed them the course website and showed them where they would be doing their tutorials and labs and stuff. Some people were asking what to do in the lab, so I think I didn't make this completely clear. However, this one isn't worth covering in the next tutorial, because they will remember the website from the previous lab.
I went through some of the tutorial questions. One of them I remember clearly - it was, "how many marks are attending lectures, tutorials, and lab worth?". As a note, lectures, and tutorials are worth no marks, and are completely non-compulsory.
While it is honest to make this clear at the start of the course, I am not sure of the pedagogical benefits of this. If we make it definitively clear that attending lectures and tutorials are worth no marks, people will naturally go and skip them, even if they're behind. It may have been better to not mention it explicitly, so we can trick people into attending, at least for a few weeks until the course.
But of course, that's not quite moral.
- I explain what Linux was. I contextualised it with a funny story about how I managed to accidentally wipe my windows partition, which worked somewhat well.
The class seems kind of half enthusiastic and participating, and half detached. I suppose that is a combination of poor communication (some students have poor english), and also because
- After that, I gave them a brief revision of the unix commands. I wrote the commands they would need on the board for visual persistence, and briefly demonstrated using some of the commands on the terminal of my Ubuntu computer. Then I got them to try it out themselves by writing the Unix commands on a piece of paper. I tried to come up with a realistic example (sorting files into folders), and encountered minor problems.
The lab used the 'cp' command. Normally you would use 'mv' to achieve such a task, but I didn't want to try to teach them too many commands at the same time. Therefore I restricted the 'action' commands to 'cp' and 'rm [-r]' and the 'information' commands to 'cd', 'pwd', and 'ls'. That way they had less commands to revise, and thus would learn more easily. This caused a minor amount of confusion: one or two people asked 'hey why aren't we using a cut operation rather than copy+paste and remove?
Note: rmdir does not remove enclosed files of a directory. Can be good or bad.
During the unix exercise, I tried to explain linux and tried to draw as many analogies as possible to Windows and Mac OS operating systems. This is probably one of the easiest ways for them to understand, since the Windows and Mac OS schemas in their mind are the most similar to the Linux schema are thus the most easily linked to the current content they are learning. In retrospect, this was probably a good decision, and I will improve the specifics of my analogies over time.
- At the end I asked if anyone wanted to come up and demonstrate their example. I'm not sure that targeting one person was the best idea - only one person gets to demonstrate their example, and the others feel as if their work may have been wasted (produced no positive result) if they do not have a strong awareness of their own learning.
Conversely, the disadvantage of getting every person to participate is that not everyone will be up to date, and if you are forcing someone to participate when they are not confident, then that possibly gives a negative atmosphere to the classroom. Better to let the people participate if they want to participate, and leave the rest of the people be.
Perhaps better, to engage everyone in the class, would be to get each pair to complete one line. Getting people to get into pairs for this exercise is essential if you are getting everyone to participate, because then no single person is targeted. The larger the group, the less the participation of each person, but the lesser the pressure on each person.
For more difficult tasks, you would want larger groups (say, up to 4 people), but for easier tasks, you could get people to put their responses in individually or in pairs. For example, in the exercise where you introduce the person next to you, there is very little pressure and it is basically impossible to get wrong. Therefore, you can get every single person to participate individually at no negative cost.
- I followed up the unix exercise with some additional unix demonstrations. I tried to include some humour while I demonstrated rm and rm -rf
In reflection, I think I should have skipped unnecessary commands like rm and rm -rf, and simply taught cd, ls, and cp. The reason I should teach cp, even though they wouldn't use it, is because they are using the cp command to copy example programs from the icecold sample files. This way, they gain a (slightly) better understanding of what they are doing. If I skipped the unnecessary commands, then I get more time to cover C (which, in retrospect, would have been an excellent idea). I didn't get time to cover debugging and telling them how to deal with errors, which was one of the most important parts.
- Afterwards I opened a C program to print a smiley face. I wasn't able to explain much about it, and basically said, "here is what a C program looks like, don't worry too much about anything, look it prints a smiley face". I had been forewarned that the students would not have a deep understanding of compiling, so I made sure to revise that and talk briefly about what compiling was (in summary, turning your instructions into executable machine code). I obviously did not make this clear enough, and it was the end of the lesson, so it's something I should cover in more depth next lesson.
- I tried to make the joke about debugging ("this error is really good! why? [looks around at class] because if it wasn't for errors, we'd be unemployed!") and it worked for about half the class, but wasn't as effective as I would have liked. This may have been due to the somewhat tense atmosphere of the first lesson (the students don't know what to expect), which I had failed to break into a more casual atmosphere.
Atmosphere isn't what I'm good at doing. Atmosphere is what comedians and performers are good at doing.
- I covered gedit and the ampersand in some depth. People asked questions, and wanted to know the difference between running it with ampersand and running it without ampersand, and thus I spent a fair time demonstrating on the projector what happened with and without the ampersand. The lab exercises explicitly mention using the ampersand, so I don't think this needed to be covered in any depth. They had a reference point, so when they saw the command in the lab, they hopefully understood the purpose of including the ampersand.
- I was unable to cover piazza in time. A huge mistake.
Lab
- At the start of the lab, I remembered I had forgotten to mention when labs were due, what to do in labs, etc. In retrospect, this is a good thing - you want to mention a fact as close as possible to when it becomes relevant (i.e. mention it just before the lab). This is for two reasons. The first reason is because you don't want them thinking about the lab during the tutorial, you don't want their working memory to be used on lab facts before it is necessary. The second reason is that your memory is clearest closest to when you learn something, and this way they will keep the idea in mind clearly during the lab.- At the start of the lab, I had a fair few people asking me, "So what are we actually doing?" I think this was a mistake on my part - I had only showed them once to navigate to the course website, so they didn't have it very strongly in their mind
- We had a huge variation in the students. Some students coped very well with the explicit instructions and were very good at following them. Some just didn't understand what they were meant to do, and had trouble. For example, some people had difficulties debugging the C code. C debugging output is notoriously difficult to understand.
I think this was partly the fault of the lab questions, it was not entirely explicit what they were meant to fix in the 'broken program'.
- Some people were confused by the learning activities. For example, one of the questions asked them merely to open a program, and see what it did. They seemed confused because there was no way to track what they did. Some thought that the terminal was proof of them completely the activity.
This appears to overall be a fairly common theme throughout the course. The students are accustomed to being accountable by providing proof of their work, and are not used to learning for the sake of learning. This is not a good thing, but it is not beyond what I expected. High school students are generally like this.
The main question is: do I have the time and/or effort to instil an intrinsic appreciation of learning into these students, despite the fact that it is a lower priority? The answer is a definitive no, but it is definitely something I will keep in mind for the future.
After this lab though, they will understand that I will judge their programs merely by their output (and opening the program and giving style feedback if I have time). Perhaps when they complete the exercise, I will ask them, do you want additional feedback on your code?, and they will be able to choose to get additional feedback or gtfo the lab, depending on their preference.
- A common theme among the students is, they are not sure what they are meant to be doing. They don't have a very good track of their purpose for being in the lab. I think that will rectify itself as the course progresses, they learn a bit more about what they're meant to be doing in labs, and become more familiar with the environment.
- Some students had trouble because the commands in the lab were like '% command'. The terminal on the lab computer had a $ sign, and the % was confusing regardless.
Students also had trouble copy-pasting commands in the terminal. I taught some how to copy-paste on linux, but perhaps it would have been better for them to practise writing out the commands manually.
I'm not sure about this whole explicit instructions thing. The lab instructions also tend towards a huge wall of text, which is menacing and unfriendly, especially for those whose main language is not English.
- Piazza was a nightmare. The students had not accessed Piazza before, and Piazza requires activation via your zmail in order to login. The problems caused by Piazza were mostly because I got a huge bunch of unenthusiastic students, so many of them hadn't even bothered to set up their zmail, and I had to simultaneously show them how to set up zmail and get into piazza.
However, we cannot entirely fault the students. My responsibility as an educator is to be didactically effective no matter the circumstances. The students not setting up zmail should have been something that I had expected, rather than something unexpected which destroyed the learning within the lab and made the entire lab unpleasant.
The students are unaccustomed to dealing with errors, and I must make it clear that errors are ok. I recall the lecturer mentioned something similar a few times, too. Make sure that students know that errors are ok!
- Is piazza even of benefit? I don't know. The students who are confident to post on course forums, it will benefit them a lot. But since the first experience is overall unpleasant, I'm really not sure whether it's valuable.
I suppose we will see how beneficial it is (as opposed to emailing the tutor) as the course goes on.
- As one of the lab exercises, the students had to email me. This was great! Some of them felt the freedom to write a comment of the course of their own accord, which was actually amazing. The people who finished early generally had positive feedback "Hey I am enjoying this course", "I am looking forward to this course", etc., while those who finished later had negative feedback, "I hope the explanations will be better in future", ":(", etc.
The good feedback is an amazing sign, and somewhat dispelled my Piazza nightmare somewhat. Even the bad feedback was good, because the students feel enough liberty to send me their thoughts - I am a casual helper rather than a formal boss or a formal teacher. Next tutorial, I need to somehow raise the spirits of people who struggled a lot with the Piazza task.
- I marked people off by writing their grade down on a piece of paper. I tried my best to recall their names, and having them email me as part of the lab helped a huge amount with that. I lost that piece of paper, so hopefully I can recover it sometime.
- There was one particular student who irritated me a great deal. When he had problems, he would physically get up and try to bother me about them, even when I was helping other students. During the lab, I think I grew exasperated and my attitude became noticeably less pleasant towards all the students. I was simply tired of this student bugging me about every single possible instruction.
He had huge communication problems, English not being his native language, so even when I helped him, he had difficulty understanding my instructions. Language barriers is a huge issue in every classroom, because even if they understand your instruction, they have a greater cognitive load than other people (since the cognitive load of processing the language in working memory is much greater).
In the next lab, I will endeavour to be much more patient, to speak extra-extra-slowly, to enunciate my words extra clearly, and to develop a far better non-verbal communication. For example, usually I avoid pointing at the screen because it intrudes somewhat on their personal space, and I want to ensure they understand what I said. For this student, however, I think the communication advantages of pointing at the screen outweighs the possible negative consequences. (Additionally, this student seems to have little understanding of personal space). I will try to use many non-verbal techniques like this, and simplify my sentences, to one word if possible. e.g. "Good", "Bad".
To include in following class
- Varied and interesting examples using C- Reiterate the point about machine code
- Make lots of intentional errors so the students feel better about dealing with errors.
- Raise the spirits of people who struggled with last lab
- Make sure my attitude is 100% positive. Speak super super slowly and carefully. Use more non-verbal communication.
No comments:
Post a Comment