Compass: Update

I'm currently in the process of delegating Compass to different volunteer presenters, so that they can come up with content for each week. It's useful because I don't have all that much time to do everything.

Which means my duties are reduced to mostly talking to other presenters and overseeing the workshops and checking out how everything is going. I have noted a list of things I often say to demonstrators and presenters in and outside of the workshops.



Presenters (advice on content selection):
- Most important! Maintain a strong awareness of the students' perspective throughout. Try to imagine what logical jumps they would have to make to write a program, and measure that as an indicator of whether your exercises are too hard.
- Make sure the content is obviously useful or relevant. If the students doesn't see the point of an activity, they won't really be motivated to do it, and the learning schema will be all screwed up
- Try to make exercises that are fun and produce a cool result
- Try to make sure that student have opportunity to experiment on the exercises. The more they experiment, the more deeply they will understand the features being taught to them.
- Additionally, if everything makes something unique and creative, they get a sense of uniquity and achievement, and people can try out other people's programs.
- Some features (e.g. booleans) are unnecessary, do not add value, and generally are not worth teaching. Some features (and/or) are not strictly necessary, but add enough value that it is sometimes worth teaching.
- Revision exercises should be quick and educational. Real exercises should be extensible
- Diagrams are often useful when explaining complex concepts
- Do not introduce new features too quickly, otherwise the students will lose the power to experiment and will resort to merely copying code.
- Ask yourself, would you have fun writing this program? If not, why would the students have fun?
-Put up a code example beforehand for early arriving students to revise before the start of the workshop


Demonstrators:

- Actively look for student to help out. Look at students' code, and suggest extensions or ideas if they
are finished with their work.
- Make sure that the students are quiet when the presenter is talking. This is really important, because otherwise it's hard for the presenter.
- Make sure you talk very slowly and avoid using jargon.


I usually don't give technique advice to presenters, because it takes too long to change, and also it's not worth the minor improvement. But I did have a chat to the main presenter of the other stream before the course started:
- Maintain a strong enthusiasm and energy throughout. If the students see that you are excited and energetic, they will be excited and energetic too. You have to look like you care about the stuff you're teaching.
- Physically point to the part of the code you are talking about.
- Maintain eye contact with the students when you are talking to them and they should be looking at you. Switch your eye contact to the code when you are illustrating a code concept, so they do not look at you.
- Talk to the back of the room. good vocal volume.


There's an interesting technique that sometimes ends up being used in the workshops, which is making mistakes in the code and getting students to look for it and pick it up. I think this is overall good, because it keeps students focused and gets them to actively look for problems. They simultaneously become better at debugging their own code.

The reason I don't like ideas like this, however, is the disadvantage that only some students will participate and answer the questions ("What's wrong with this code"), and as a result, other students may feel slow or left out. Additionally, debugging problems can be easily fixed by the demonstrator when they are helping the students.

Ideally, there are many different ways of keeping the presentation active and alive, and keeping the students engaged with the content. Intentionally putting code isn't the best way of doing this - it could confuse the students, especially when introducing new topics. The demonstrators, if very competent, would easily explain the debugging errors to the students when required, and can probably accommodate each student more efficiently.

Thus this technique works better when:
- The presenter is not highly competent and engaging
- The demonstrators aren't terribly content.
- The content being covered is well-known or well-reviewed content, where the students will not be confused by making mistakes in something unfamiliar.

As our presenters and volunteers (generally) aren't terribly competent/engaging/good at explaining, I think this method will remain effective for the revision topics - basically any revision section of a workshop. The ideal method will be worth introducing later in the year, maybe, when presenters and volunteers are more experience, or when I'm presenting and I've been able to do a lot of content preparation.


We mostly follow teaching by example. Teaching by example is always a good way to explain concepts to beginners. We follow up the teaching by example with constructivist, interactive learning - the students write their own creative programs, and solidify the understanding of what they have learned by example.

With the infinite freedom of this course, this is what we have come up with. I feel like this structure is fairly solid.