Re: [Edu-sig] introduction
In a message of Thu, 20 Mar 2008 21:49:39 -0400, Richard Enbody writes:
We randomly assign within assigned labs -- the labs have 16-20 students. We assign within labs because there is a time, the assigned lab, when students can meet. That is, the excuse "we couldn't meet" is not valid. On a subsequent assignment we roll the dice again within the lab and ensure that the same two do not pair up again. If a partner is a 'no-show' we allow them to match with anyone else who is also paired with a 'no-show'. We have considered various matching schemes, but if I remember correctly, random is supposed to be the best way -- as opposed to trying to match students.
16-20 is considered oversize if you want to get everybody pairing with everybody, so I would partition my class into 3 groups of 6 or 8 (or maybe 2 groups of 8 for the 16 case), and then build a rotation schemee for each group, not getting the groups to interpenetrate. Random isn't exactly what you are looking for. When people say that it is better to partner randomly, what they mean is that you need a mechanism to keep people who like working together from doing just that. But simple randomness isn't going to ensure that everybody gets to pair with everybody unless there are a really large number of sessions for 'changing pairs'. I've got some more questions: How long do you have to work with these people? How long is a lab, and how many rotations do you try to fit into a lab? and How long is a course, and how many labs in a course? How much work do you expect people to do on the programs outside of lab time? Are the labs self-contained, or do they build on each other's work?
We know about the 'driver' and 'thinker' roles and that the students should change roles. We talk about it with students, but do not try to enforce it.
I've always had problems with that concept -- or rather, with the idea that the 'driver' is the one doing the typing, and the 'thinker' is the one doing the watching. Some students I know think a lot better when they are typing than when they aren't. Some students who aren't typing pretty much dictate what the typer is going to type. So I don't know if I am just doing something wrong, or if the model is unrealistic.
I like your model, but it would be difficult to implement here -- too many students have too much going on (unfortunately, for many that is a job to help them get through school).
I have this problem, too, which is why we mostly can only experiment with things like that in Summer courses, and camps, where you are trying to pack what would normally be taught in 4 months or 8 months into 2. And still there are some people who cannot make the time.
On your question about not having marks -- that isn't an option. On your question, 'what if 85% got 85%?' That would be great! Our grading scheme is not competitive -- if you get the points, you get the grade. In theory, everyone could get a 4.0 (A). My understanding is that you need such a scheme for pair-programming to succeed. However, with enough students we seem to get a spread out distribution.
This is an indication that your weaker students aren't catching up enough. The question is, why? If you are trying to get rotation through groups of size 16 or 20, that is probably one contributing factor. If the assigment runs out before the students who began working on it can get back to it for a second pass, while having done other things in the meantime, then that is another factor. There are others I have seen, and some I have only heard about, such as trying to do pair programming and not doing test driven design. Are you doing that, as well?
These questions have got me thinking!
Great. :-)
-rich enbody@cse.msu.edu
Laura
On Thu, Mar 20, 2008 at 11:54 PM, Laura Creighton <lac@openend.se> wrote:
We know about the 'driver' and 'thinker' roles and that the students should change roles. We talk about it with students, but do not try to enforce it.
I've always had problems with that concept -- or rather, with the idea that the 'driver' is the one doing the typing, and the 'thinker' is the one doing the watching. Some students I know think a lot better when they are typing than when they aren't. Some students who aren't typing pretty much dictate what the typer is going to type. So I don't know if I am just doing something wrong, or if the model is unrealistic.
Hi Laura -- I think your point about randomizing, and your other point about how the roles aren't always so cut and dried, are connected. The real point of pair programming is the old adage "two heads are better than one" (and yet "too many cooks spoil the broth" i.e. just because two usually works doesn't prevent five from being routinely disastrous). In Vilnius, I was paired with this talent from Google Warsaw who barely knew Python, but was through the roof smart and knew Java already, so was taking this opportunity to suck up Python like a sponge. Since I'm happy teaching Python, our productivity was very high, not saying other pairs weren't higher (you generally don't need to "grade pairs" in XP, a corollary to the frequent repairing operation, garbage collecting of bad karma that way). In other jobs, I'm paired with this guy who clearly knows Python way better than me, along with C, Eiffel, and everything else, so I'm just at the feet of some guru, maybe having panic attacks about the likely fate of my ego on this job. And that can work. I don't mind worshiping guys 'n dolls ** as long as we get the job done. It really helps knowing the randomizer will come along pretty soon and split us i.e. I'm way more willing to be productive in short term partnerships than "your pair programmer for life" kind of arrangements. Yes, it's only a matter of time before the psychologists fill the shelves with their analyses of XP techniques, why they work, or are dangerous, making the whole field way more introspective -- often not to the liking of engineers, who went to computing in spare environments to escape a steady drum beat of mumbo jumbo all the time. More fun to make spaceships fly around in Blender or whatever. But let's be clear about something else while we're at it. I live in Portland, and Europython in Vilnius isn't any "just anywhere" either. So I'm professionally involved with some cutting edge XP proponents, and that's not equally true everywhere in the country. A lot of colleges and universities have no choice but to mirror corporate middle America or wherever and there's just no way a true "anybody with anybody" XP shop is going to emerge so spontaneously in the classroom, let alone in the work place. It's just not a part of the culture, whereas maybe at Microsoft (where our guest speaker was from) it is. Microsoft is enormously prosperous for a reason, not just because Windows sucks A lot of the Pycon talks were about "why Python sucks" in various ways -- a whole genre, an inhouse counterculture. Like one guy hates __import__, how it works now. I'm not saying I followed in detail, but that didn't keep me from liking the vibrancy -- from __future__ looks bright. And I *really* liked the All About Unicode talk. Very precise and clear, helped me a lot. How ASCII became Unicode is what we feed to 2nd and 3rd graders in our neck of the woods, so basic to everything, like the birds and the bees. Kirby
I don't mind worshiping guys 'n dolls ** as long as we get the job done. It really helps knowing the randomizer will come along pretty soon and split us i.e. I'm way more willing to be productive in short term partnerships than "your pair programmer for life" kind of arrangements.
** allusion to a musical. I grew up in a family where the dad "doesn't like musicals" (ICEscapades either) and I too am not in the habit of delving in that genre, though I don't say I hate them, on the contrary loved the last couple (one starring a Wanderer's daughter at Jesuit in Beaverton, the other Wicked in Hollywood over Xmas), but in the name of pair programming and mixing it up more, why not? Plus our household *does* officially approve of the musical episode in Buffy, given we're such Joss Whedon and Peggy Parsons fans in these parts. More pop culture allusions sorry, and yeah, I'm a huge Britney Spears fan (my friends will tell you) who in turn helps me more appreciate Madonna. Like that Hate Me guy too, and that Over the Hedge guy starting to like. More in my blogs for the morbidly curious :-D. Kirby
In Vilnius, I was paired with this talent from Google Warsaw who barely knew Python, but was through the roof smart and knew Java already, so was taking this opportunity to suck up Python like a sponge. Since I'm happy teaching Python, our productivity was very high, not saying other pairs weren't higher (you generally don't need to "grade pairs" in XP, a corollary to the frequent repairing operation, garbage collecting of bad karma that way).
Just to give more background, this technique of switching quite often, like every 90 minutes, is called "promiscuous pairing" in XP and is considered advanced, not necessarily a good starting place, per this blog entry: http://blog.excastle.com/2006/07/25/promiscuous-pairing-and-beginners-mind/ The presentation I was referring to in Vilnius was by Arlo Belshee as you'll see on this schedule (Wednesday): http://indico.cern.ch/conferenceTimeTable.py?confId=13919&detailLevel=contribution&viewMode=room He's with BlueTech, not Microsoft: http://www.linkedin.com/pub/0/13b/0ab I'm not really sure how much XP is used in Redmond, not being an insider there (though with friends on the inside). Let's just say I suspect quite a lot, as savvy software engineers tend to adopt best practices out of necessity to keep up. Anyway, we're using it around Portland and if I get that adult student gig I'm angling for (building a tag team) you can be sure we'll be writing lots of unit tests (which sometimes double as "demo defs" for a Python module, i.e. they advertise what it does). Kirby
participants (2)
-
kirby urner
-
Laura Creighton