Pages

Wednesday, 4 July 2018

Intermediate level Python workshop - review

It didn't go as terribly as I'd expected. I got lucky with my improvisation and pulled off some off fairly successful exercises. However, there were mistakes - so many mistakes. You can't help but admire the people at the top because of their incredible preparation.

Simply trying not to destroy your own workshop with a critical mistake requires hours upon hours of preparation. Devising a workshop where there are relatively few observable flaws is on a completely new level.

Unlike Starcraft, teaching doesn't have replays. The best you can do is write reflection blog posts after the fact about things that you remember. But the valuable lessons cannot be found in the things you remember. The valuable lessons can only be found in the things you didn't notice, or the oversights you made, or the things you forgot.

This is why I think it's really important to take a video of yourself when you're presenting so you can identify and revise flaws in your own teaching. I think the reason I can motivate myself to do this is because I've learned of the value of replays and how important it is to revise the things that you yourself failed to notice.

Watching replays of yourself exposes all your flaws. It's damned painful sometimes. But you've gotta do it. You've got to keep moving forward.




Before I jump into the summary of the workshop, I think I've learned a few important lessons.

1. It's really not only about the presenter, or even only about the workshop. There are so many side channels that you have to consider when you're designing a workshop, such as the quality of the workshop volunteers and the students entering.

As a workshop presenter, the power you have to influence occurrences outside your workshop is rather limited, but you could do things like ask to pick the students for your workshop yourself and give the volunteers a pep talk before the workshop started.

But more on the workshop volunteers later.

2. You can only do so much planning for a workshop. First you have to pick the learning area(s) of the workshop. The exercises should be related in some way by the knowledge/schemas needed to complete them successfully, so that we can continue to reinforce the core concept in the workshop and advance in complexity. Additionally, reinforcing the core concept with lots of exercises will allow the students to retain the information better.

In my workshop, the topics I ended up covering were "Python Libraries" and my learning areas were "Revision", "requests", "Lists", "matplotlib",  and "PIL". However, I couldn't help feeling like the workshop was heading in the wrong direction. My learning areas weren't really all that related, so they didn't build upon each other. A lot of problems were caused, and we'll need to figure out why. I'm thinking of making my workshops exercise-centric rather than learning-area-centric.

Now that I think about it, it's not really about the 'learning areas' when you're running workshops of this scale. Nor does it need to be, I think. Learning areas is heavily tied to the concept of a syllabus, where students are required to learn certain pre-requisites to preserve structure in an overall order of things. I think topic areas or learning areas could be useful when you're thinking of a 10-week workshop or designing an overall course structure (both super time-consuming operations). But I think I shouldn't have bothered coming up with topic areas, because the scope of the workshop was so short. I could have simply come up with a few vaguely related exercises and made that work. I wasn't really trying to build towards any goal, nor is building towards a goal really viable in a workshop of such a length.

Basically, if you're running a one-day workshop, picking a few vaguely related exercises is a good idea. Building towards understanding a complex program at the end is a cool objective, but there are so many ways it could go wrong. If your exercises really aren't all that related at all, then you get to 'restart' every hour or so, and the people who didn't really get it or who don't learn as fast are able to 'start again' at the same level as everyone else.

I think a presenter's repertoire of exercises is kind of like his tools of trade that he brings into each workshop. Creating a new successful exercise is an arduous process that requires a lot of a failure, a lot of thinking, and a lot of luck.

I'm pretty sure creativity is just continuously trying again when your first attempts don't work. You're bound to come up with something new eventually.




Onto a review of the actual exercises run:

- Web scraping is a crap topic. I don't know why I thought it would ever be a good idea. The whole idea and power behind web scraping is that you can scrape theoretically any website on the internet and collate interesting data about things that you want to. There are so many problems with this, foremost being the problem that data on different websites is formatted differently and not easy to scrape.

I mistakenly thought that I could pick a single type of website to scrape and therefore make it easier on the students, but 1. that invalidates the whole point of web scraping, might as well get the data from a file or something, and 2. html is damn hard to scrape at an intermediate level workshop. The best you can do is regex or something, and the pre-requisite knowledge to extract lists of data from regex is ridiculous.

I think web scraping could be an advanced topic where students are able to select their own topic area and produce interesting insights - not merely by scraping statistics websites, but by scraping trends on twitter or scraping their friends' profiles on facebook or something. Definitely not at this level, considering chucking the topic entirely.

What I ended up doing was getting them to scrape from Project Gutenberg's plain-text archive of books, which they then could analyse for word frequency and letter frequency and produce interesting facts. I don't think this exercise was entirely unsuccessful, and it definitely has some merit, but the web scraping is a tool that we use to get the book into a string, rather than the main focus on the exercise. To be honest, I prefer web scraping to reading from a file, it's much nicer and the process is much easier.

Advanced students were told to run letter frequency analysis and digraph (two-letter-frequency) analysis for those that already knew how to use for loops.

No comments:

Post a Comment