Debbie hated math and resisted everything to do with it. Tested at the bottom of the scale. She learned to program the computer because this let her play with words and poetry, which she loved. Once she could write programs she found a way to tie fractions into words and poetry. Writing witty programs about fractions led her to allow herself to think about these previously horrible things. And to her surprise as much as anyone's her score on a fractions test jumped into the upper part of the scale.What you do as a job programming in C#, Java, JavaScript or whatever has very little to do with the way people use coding to learn about learning. That's the most disappointing thing about the article. It is the terrible idea that learning how to code lessens the world if you do it wrong. Learn to code backwards in time in Latin in Perl but don't listen to anyone who says you shouldn't code.
Friday, May 18, 2012
Constructivism - Why You Should Code
I think this article on why you shouldn't code is wrong. It's wrong in a way that I was wrong in high school that I would never need to know German, art or biology. It's wrong in the way I was wrong about never needing to know set theory or relational theory or category theory. But it's also wrong in the ways I will never really know, "Computer As Condom":
Monday, May 14, 2012
Lectorial
I just finished a study group on Learn You a Haskell for Great Good. Which was a great experience, for many reasons, but I think the way each session was structured into a combination of lecture and tutorial deserves particular attention.
The weekly structure was fairly straight forward: a chapter leader covers a chapter the week before the rest of group, writes a summary and some programming questions. The weekly sessions took about an hour and a half. This consisted of the chapter leader going through their summary allowing the group to interject with questions and answers (if the chapter leader didn't know) or there might be some furious Googling to find a good reference or answer that someone half remembered. The programming questions and answers would usually go around the table, each person would answer a question and the others would then comment on it or show their answer if it was particularly different (or shorter or whatever). The time was roughly 60/40 from lecture to programming/tutorial.
Compared to university courses, where you often had two hours of lectures and then one or two hours of tutorials often spread out over a week, this arrangement seemed to be very time efficient. The other advantage was getting the students to run the study group. The chapter leader has to spend a lot more time making sure they understood the chapter in order to answer any questions that would come up during the review and to set the programming questions. For me, setting the questions and making sure you had answers (and by the end of it tests to help people along) was probably the best part of the learning experience. There was no real hiding if you hadn't done the answers either - partially because it was such a small group but also because of the high level of participation.
It'd be interesting if there were university courses where you were graded not just on an examination and assignments but the questions you set and if you were able to run a small group of people through a class. It would also make tutorials more relevant which are often dropped by students.
It seems "lectorial" also means, "large tutorial in a lecture hall to give context around information given in lectures". They also mention small group activities and class lead presentations so there is some overlap.
The weekly structure was fairly straight forward: a chapter leader covers a chapter the week before the rest of group, writes a summary and some programming questions. The weekly sessions took about an hour and a half. This consisted of the chapter leader going through their summary allowing the group to interject with questions and answers (if the chapter leader didn't know) or there might be some furious Googling to find a good reference or answer that someone half remembered. The programming questions and answers would usually go around the table, each person would answer a question and the others would then comment on it or show their answer if it was particularly different (or shorter or whatever). The time was roughly 60/40 from lecture to programming/tutorial.
Compared to university courses, where you often had two hours of lectures and then one or two hours of tutorials often spread out over a week, this arrangement seemed to be very time efficient. The other advantage was getting the students to run the study group. The chapter leader has to spend a lot more time making sure they understood the chapter in order to answer any questions that would come up during the review and to set the programming questions. For me, setting the questions and making sure you had answers (and by the end of it tests to help people along) was probably the best part of the learning experience. There was no real hiding if you hadn't done the answers either - partially because it was such a small group but also because of the high level of participation.
It'd be interesting if there were university courses where you were graded not just on an examination and assignments but the questions you set and if you were able to run a small group of people through a class. It would also make tutorials more relevant which are often dropped by students.
It seems "lectorial" also means, "large tutorial in a lecture hall to give context around information given in lectures". They also mention small group activities and class lead presentations so there is some overlap.
Subscribe to:
Posts (Atom)