So this post is really more of an internal brain dump to all the tutors who were present during the course - everyone is welcome to comment and add their input but if you want to get to the exciting stuff skip to the next post.
So guys the main change I think we should make next time is to limit the extent to which we use the live terminal display. Instead of having it up the whole time I think we should only put it up when showing the students examples as this served as a bit of a crutch for the lecturers and a bit of a distraction for the students.
So guys the main change I think we should make next time is to limit the extent to which we use the live terminal display. Instead of having it up the whole time I think we should only put it up when showing the students examples as this served as a bit of a crutch for the lecturers and a bit of a distraction for the students.
I also think that a lot of the students struggled initially with the idea of a variable, you must remember is that a lot of the kids are quite young and haven't really come to grips with basic algebra yet. Perhaps we should use a more visual demonstration of what a variable is - for example a jar or a box (with a label of course) which can only hold one value at a time. We could then illustrate different values as cut out paper strips with 1, 2, 3, "Hello World", etc. written on them and visualize setting variable's value by replacing the contents of the box with one of the paper strips, likewise looking up the value of a variable just becomes a problem of finding the box with the correct label and seeing what is inside it.
If we handle variables that way then lists are then just a special type of variable that can store more than one value at a time. We could ask students to create a list of their favourite food, movies etc. and get some of them to write them up on the board. We could follow that up by asking them if the item at the "top"of the list is their least or most favourite one. We can then explain "front" and "back" of a list by telling them that Computers just rotate the list onto it side so instead of "top" and "bottom" we have "front" and "back". Yeah I know it is a bit simple but I think it may go down better, what do you guys think?
We also slightly confused the issue by introducing different types (string, float, int) as well as records (yeah I know tuples in Python) we should have just have kept it simple - remember the KISS principle guys!
In terms of the sequence of topics, I would introduce functions really early on (bear with me) even before we get to conditionals. So something along the lines of output, input, functions, conditionals and the rest. I think treating functions as a bit of magic is a mistake as it just confuses them later on.
I think we can describe them as a special type of program that lives inside their main program and doesn't do anything until they call it (I'm sure we can come up with a good metaphor for this - several spring to mind). To reinforce the idea of a function we could ask the students to create a special raw_input method called my_raw_input which prints 3 starts, asks the user for a number and then prints 3 more stars, so something like this:
We can extend this idea by getting them to add a parameter to control how many stars are printed e.g.:
Another one to control what the user prompt is, etc. until they are comfortable with the concept. We should do this in an interactive fashion i.e. give them the task and then go through a solution on the board and ask for questions or alternatives.
Another things I think we should consider is getting the students to group together for these interactive tasks, hopefully this will encourage peer-learning.
In terms of the tutoring process I think we do need to micromanage students a bit more. A lot of kids are embarrassed to ask for help so they do fall behind and then they start to become a bit rowdy - we should get tutors to be a bit more proactive with students that have blank screens and not only help the students who ask questions. I know varsity students somehow learn one of life's key lessons that asking questions when you don't understand something doesn't make you stupid (in fact it makes you smart) but for some reasons school tends to teach the opposite (WTF?)
I also want to throw the idea out for discussion of having some sort of fun unifying example for students to work on. Something we can develop throughout the course where they can apply all the tools they learn in a fun way. I would like to suggest something like my hangman exercise which went down really well (I had students arrive at the group asking if we were REALLY making a hangman game - they were so excited!) Anyway more on that in the next post!
As we all know this course is a bit of an ongoing process (I think we have now run it 3 times now?) and each time we learn something new about how to teach programming - which for me is one of the really exciting parts.
On a similar note I was also chatting to Stefano and a couple of guys in the lab and it seems that there is a lot of interest at UCT in offering a Python boot camp. Yes Marco I know we also chatted about this previously - but I know Rudy for example was looking for people to tutor Python to the Geomatics crowd and I am sure the Bioinfomatics and Chemistry crowd are also quite keen. Perhaps we should approach the Science/Engineering faculty about offering a Vac or Summer school style bootcamp in Python "literacy" (enough programming in Python to do useful things - but not all the theory we cover in CS) - so more like practical programming?
In terms of the sequence of topics, I would introduce functions really early on (bear with me) even before we get to conditionals. So something along the lines of output, input, functions, conditionals and the rest. I think treating functions as a bit of magic is a mistake as it just confuses them later on.
I think we can describe them as a special type of program that lives inside their main program and doesn't do anything until they call it (I'm sure we can come up with a good metaphor for this - several spring to mind). To reinforce the idea of a function we could ask the students to create a special raw_input method called my_raw_input which prints 3 starts, asks the user for a number and then prints 3 more stars, so something like this:
def my_raw_input_1():
print "*" * 3
raw_input("enter a number: ")
print "*" * 3
We can extend this idea by getting them to add a parameter to control how many stars are printed e.g.:
def my_raw_input_2(numStars):
print "*" * numStars
raw_input("enter a number: ")
print "*" * numStars
Another one to control what the user prompt is, etc. until they are comfortable with the concept. We should do this in an interactive fashion i.e. give them the task and then go through a solution on the board and ask for questions or alternatives.
Another things I think we should consider is getting the students to group together for these interactive tasks, hopefully this will encourage peer-learning.
In terms of the tutoring process I think we do need to micromanage students a bit more. A lot of kids are embarrassed to ask for help so they do fall behind and then they start to become a bit rowdy - we should get tutors to be a bit more proactive with students that have blank screens and not only help the students who ask questions. I know varsity students somehow learn one of life's key lessons that asking questions when you don't understand something doesn't make you stupid (in fact it makes you smart) but for some reasons school tends to teach the opposite (WTF?)
I also want to throw the idea out for discussion of having some sort of fun unifying example for students to work on. Something we can develop throughout the course where they can apply all the tools they learn in a fun way. I would like to suggest something like my hangman exercise which went down really well (I had students arrive at the group asking if we were REALLY making a hangman game - they were so excited!) Anyway more on that in the next post!
As we all know this course is a bit of an ongoing process (I think we have now run it 3 times now?) and each time we learn something new about how to teach programming - which for me is one of the really exciting parts.
On a similar note I was also chatting to Stefano and a couple of guys in the lab and it seems that there is a lot of interest at UCT in offering a Python boot camp. Yes Marco I know we also chatted about this previously - but I know Rudy for example was looking for people to tutor Python to the Geomatics crowd and I am sure the Bioinfomatics and Chemistry crowd are also quite keen. Perhaps we should approach the Science/Engineering faculty about offering a Vac or Summer school style bootcamp in Python "literacy" (enough programming in Python to do useful things - but not all the theory we cover in CS) - so more like practical programming?
Anyway stay tuned to this post - I may be updating it with a couple more ideas once I've worked them out.
Till next time ...
Pretty much what Jason said :)
ReplyDeleteI also felt there were some areas where we might want to "dumb down" the material a little bit, especially with variables and data types. Some kids struggled with the different between an integer and a string, especially since they LOOK the same, from their perspective.
In all fairness, I'd say 80% of the material does not need much attention, the rest maybe a bit of a rework here and there, but overall the course went great and the kids really learned a bunch over the weekend. It was a bit surprising to learn one or two things about Python myself while listening to the lectures :)
Having said that, I was impressed with how many did follow the material and how few fell behind. Of course, having all those tutors around did address that problem, and that's something I felt you all did brilliantly - moving around, engaging the kids and getting everyone on track all the time.
I've been involved with a few of these type of events before, and this is the first time that I saw enough tutors moving around, so well done on that!
We might want to look at making the course notes more interactive, perhaps get some company to sponsor pens (innocent look) and have the kids complete little crosswords or something as part of a contest? The old carrot trick usually works wonders on donkeys, kids and even children.
As for the summer school idea - what a great thought - more people at university level need to be shown that programming isn't scary, it can be fun and there's plenty of ways to use computers in other disciplines as well.
Harp to harp on regarding variables: keep away from the C/C++/Pascal "box" metaphor which falls down when you write your first function and expect to be able to change the value stored in the "box" called "x" that you passed to the function.
ReplyDeleteThe "dictionary" metaphor is far closer to the truth considering that Python namespaces are dicts. To wit: Assigning to a variable in Python is like defining (or re-defining) an entry in a real-world dictionary. Metaphor is easily demonstrated in action with a two-column table. When explaining functions explain that the function has its own dictionary so that assigning to "x" only changes "x" inside the function.
For the Stellenbosch course, I think top priority should be re-writing the exercises. Many of the the end-of-chaper problems are too long/boring to write out, and some target obscure features that might only be briefly mentioned in the lecture.
The unifying example is a goood idea - worth working on that one.
Yeah I definitely agree with Ewald that we need to be more interactive with the theory part of the lectures. One of the great things I remember from the first couple of times we ran the course (when we used Idle) was how we could get the students to follow along with the lecture. Hey Marco remember when you asked them to calculate what 7 / 2 is and their surprise that it wasn't 3.5.
ReplyDeleteI love that approach as it really drills the point home. To Graham yeah I think you are right on one level but I don't know if the table idea works until they really get what a variable IS. We have tried that approach before with various success. I think Marco is rather fond of using tables when he lectures and he does quite a good job with them. What ever we decide I think we need to also illustrate how variables change when a program is run - so maybe a table where we illustrate the value of the variable at each line of code.
My main worry with a table based approach for introducing variables is that it will work for the older kids but not for the younger ones. That said I am no expert by any definition so perhaps what we should do is experiment a bit with both and see how the kids cope? To resolve the scoping issues for the "box" approach I think we can treat functions as black boxes which live in their own little worlds and go from there?
Anyway great to get some feedback, can't wait for the meeting it will be good to get everyone around a table.
Just another point for discussion is which IDE to use for the next iteration. I think perhaps we should rethink Wing as it has a couple of issues which make it unsuitable for teaching certain concepts. E.g. For infinite loops with no input statements nothing is displayed until the loop terminates. Since the loop is infinite that means nothing is displayed at all! This is a huge problem in teaching loops!
BTW with the infinite loops, the problem only happens in interpreter mode where it waits for the loop to complete before printing (e.g. when you "run selected text in interpreter"). When running a complete script (F5), the output is printed as it occurs.
ReplyDeleteWe can discuss variables later. The table is just for illustrating - the real metaphor is a dictionary, which kids are familiar with since Grade 1.
Yeah I think we covered most of this in the meeting on Wednesday, the only question I have is where are the minutes and who was supposed to send them around :)
ReplyDelete