9. Best approach to teaching OOP and graphics
9. Best approach to teaching OOP and graphics (Linda Grandell) I too taught Java and Python to 2 separate classes 2 years ago. Funny, the more Java I taught the less I liked it ... but then you get over it and just put up with Java's ways, plus loads of ppl have coded modules to get around many of the short comings. I still feel very negative about Java - it's so much hype and hot air really.
Pair programming is fine and works best when both are of equal ability. I would encourage you to avoid putting a stronger / more able person with a weaker / less able person - the stronger one will get very little out of it and can become quite resentful. I really cannot comment re GUI. ----------------------------------------------------------------------------------- regards Darren Payne Hurlstone Agricultural High School Ph: 9829 9222 Fax: 98292026 Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
On Wed, 23 Mar 2005 17:59:26 +1100 (EST), Darren Payne <inxdr@yahoo.com.au> wrote:
Pair programming is fine and works best when both are of equal ability. I would encourage you to avoid putting a stronger / more able person with a weaker / less able person - the stronger one will get very little out of it and can become quite resentful.
Although this is in general true... (and in fact, when I assign pairs I most often do it in one of two ways: * students with the top two grades are partners, next two, next two, and so on * Highest grade gets to pick partner from the class. Next highest grade that is not already on a team gets to pick partner from the class. Kind of like picking teams for team dodgeball, but with smaller teams) ...I remember a few counterexamples from my own experience. In most of these cases the (or three) programmers of heterogenous ability had a good personal relationship going into the project. In one case, the weaker programmer had a support role designing and implementing the procedure that would draw static graphics to the screen, while the stronger programmer wrote the logic etc.; in another case, the programmers had romantic ties that I exploited. For the lovebirds, I told them ahead of time that the weaker programmer (the boy) would have to be able to walk me through the code when they were done, and he was in fact able to do so. But yes, homogenous groups (e.g., the first strategy for picking groups above) definitely have their place. Be prepared to give lots and lots of support to your bottoms if you use that strategy.
How to assign the pairs has also been a question on my mind, so I am very glad this came up.
Pair programming is fine and works best when both are of equal ability. ...
* students with the top two grades are partners, next two, next two, and so on * Highest grade gets to pick partner from the class. Next highest grade that is not already on a team gets to pick partner from the class. Kind of like picking teams for team dodgeball, but with smaller teams)
I wonder if letting the students pair up for themselves could work? That would more or less be a variant of the second alternative above. Or does this introduce the risk of weaker students pairing up with strong students doing less work? Even learning less?
...I remember a few counterexamples from my own experience. In most of these cases the (or three) programmers of heterogenous ability had a good personal relationship going into the project. In one case, the weaker programmer had a support role designing and implementing the procedure that would draw static graphics to the screen, while the stronger programmer wrote the logic etc.; in another case, the programmers had romantic ties that I exploited. For the lovebirds, I told them ahead of time that the weaker programmer (the boy) would have to be able to walk me through the code when they were done, and he was in fact able to do so.
Sounds just great! Using heterogenous groups would most certainly be an interesting experience from the teacher's point of view. To examine how the pairs distribute the work, who takes lead and so on. However, this might be outside of the scope of my research :) /Linda
On Wed, 23 Mar 2005 14:02:15 +0200, Linda Grandell <lgrandel@abo.fi> wrote:
I wonder if letting the students pair up for themselves could work? That would more or less be a variant of the second alternative above. Or does this introduce the risk of weaker students pairing up with strong students doing less work? Even learning less?
Generally, I would say that letting students on the K-12 level pair themselves in a totally, totally free fashion leads to less learning. This strategy often leads to a classroom management nightmare. With all heterogenous groups (perhaps all groups), it's a good idea to have assigned tasks (for instance, if the program has already been flowcharted, then this person is responsible for this area and this other person is responsible for this area) or differentiated assessment (in my bf/gf example, to have the weaker student lead you through the code in order to ensure that even if they didn't come up with the code, at least they are able to read it).
Lloyd Hugh Allen wrote:
On Wed, 23 Mar 2005 14:02:15 +0200, Linda Grandell <lgrandel@abo.fi> wrote:
I wonder if letting the students pair up for themselves could work? That would more or less be a variant of the second alternative above. Or does this introduce the risk of weaker students pairing up with strong students doing less work? Even learning less?
Generally, I would say that letting students on the K-12 level pair themselves in a totally, totally free fashion leads to less learning. This strategy often leads to a classroom management nightmare.
With all heterogenous groups (perhaps all groups), it's a good idea to have assigned tasks (for instance, if the program has already been flowcharted, then this person is responsible for this area and this other person is responsible for this area) or differentiated assessment (in my bf/gf example, to have the weaker student lead you through the code in order to ensure that even if they didn't come up with the code, at least they are able to read it)
I don't have experience with pre-college students, so take this advice with a grain of salt. I use pair (even group) programming frequently in my classes. Educational studies have shown that groups of 2 or 3 help students learn better than just having them work alone. One of the real advantages of pair programming is that students can pick up techniques and useful habits from each other. In order to gain the greatest advantage of this, it's important that teams rotate around. That way students end up working with many others during the course of the term, not just their "favorite". I wouldn't worry too much about the weaker students "coasting". They will learn a lot from assisting stronger students, and if the teams change frequently, they will at some point be the stronger student where they can pass on what they've seen others do. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
participants (4)
-
Darren Payne -
John Zelle -
Linda Grandell -
Lloyd Hugh Allen