[Edu-sig] introduction

[Richard Enbody]

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.

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 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).

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.

These questions have got me thinking!

-rich
enbody at cse.msu.edu

Laura Creighton wrote:
> First, welcome.
>
> re 'how to do pair programming for a course'.
>
> There is a different between 'having a team of two people do a thing'
> and what is generally meant by pair programming.  The idea with 
> pair programming is that people work with *different* people, not the
> same other person, so that everybody gets a chance to pair with the
> best person, and the second best, and the worst and the second worst,
> with the aim to diffuse information through the group.  It's not
> clear to me, from your note, that this is what you are trying to do.
>
> How many students do you have?  There is disagreement about this, but
> there seems rough agreement that pair programming doesn't work very
> well in groups over a dozen (and some say over 6).  So you will need
> to split your class into groups and then practice pairing within the
> groups.  (At least for one assigment.  You could randomise the
> students for the next assigment.)  The thing that I have never been
> able to do, and thus never been able to do pairing as teaching as part
> of a regular course assignment (as opposed to learning camps) is
> insist that everybody has to come in and everybody work from XXX
> o'clock to YYY o'clock swapping pairs every 30 minutes, or however you
> plan on doing things.  Of course, the way I would set things up is to
> have 3 or 4 stations where different parts of what would eventually be
> one program are being worked.  After 30 minutes, one partner would
> leave for a different station.  From there on in, there would always
> be one partner (the experienced one) who has been working at that
> station for 30 minutes, and one partner who is new to it.  After 30
> minutes, from then on in, the experienced one moves -- and becomes the
> inexperienced one at a new station -- while the formerly experienced
> one becomes the experienced one at the new station.
>
> Group meetings ahead of time are necessary, of course, to plan exactly
> how people are going to solve the problem.  Otherwise you can thrash,
> as new people decide that they don't like the approach that is being
> taken, toss it, and try things their own way, only to have their work
> tossed aside.
>
> Also, its important to make sure that everybody is doing test driven
> development before embarking on a scheme like this.  Otherwise, when
> people add work, they either break things and are unaware of this
> (the other people didn't leave enough tests) or they produce work
> which isn't appreciated by the next comers (I have no idea why this
> code is here, but it looks wrong, so let's rip it out.)
>
> But around here, at any rate, students cannot, even in groups as small
> as 6, commit to _everybody working for the same 6 hours_ so we can
> implement this.  There are groups who have tried this, and had fun
> with the concept, but there are always a self-selected set that wanted
> to work this way, and could arrange their schedules to match.  Other
> people just had too much in the way of scheduling conflicts.
>
>   
>> Unfortunately, we do get students handing in code they didn't do -- a 
>> small minority, but a problem nonetheless.  I wonder what would happen 
>> to such students in a purely pair-programming environment.  Some 
>> research indicates that weak students would be pulled up sufficiently to 
>> not feel a need to cheat, but not all.
>>     
>
> You need to understand what 'cheating' would be in such a context, and
> also what 'code they didn't do' is.  If you get pairing to work
> properly, _everybody_ will be handing in code which they didn't do.
> That's the whole point.  If you are setting thing up so that people
> work together, learn together, but then go off and write their own
> versions of the thing in the end, then what you are doing isn't really
> pair programming.  So you will have to figure out exactly what it is
> that you want to accomplish with however you want people to work
> together.  But your effort at doing pair programming will be
> completely undermined if you try to also maintain the concept of
> 'this is my work'.  Because that sort of code-ownership is precisely
> what pair programming aims to remove.
>
> If this 'everybody is handing in work, only some of which they have
> done' is a problem at your school -- i.e. your most important job is
> to produce a ranking of students roughly corresponding to the best to
> the worst, and actually teaching them things is secondary, then you
> will have problems implementing any sort of pair programming scheme.
>
> So, a question -- let us say you came up with a final exam which you
> thought would test the ability of the students to know the material.
> And let us say you gave them to your class and 85% of them got 85% or
> more on the test.  Would that be a problem for you?  Your students?
> Because this is the outcome that pair programming is aiming for -- so
> if you don't want to arrive there, then you may be better off _not_
> doing pair programming, though letting people work in groups or teams.
>
> Is it possible to do without marks altogether and just do Pass/Fail?
>
> What sort of rewards and punishments you are required to implement will
> influence how well you can get pair programming to work for your goals,
> which I am interpreting primarily as raising the level of the weaker 
> students, which may be a mistake on my part.  When I was in school
> 'picking the best people to form an assignment team' (which you
> were then stuck with for the whole course) was the most important choice
> you could make in terms of getting the highest marks, and all the best
> students, who by second year, _knew_ they were the best students, had
> no interest in having anybody who wasn't one of the best students in
> their group.  
>
>   
>> I do need to get to PyCon and other Python venues, but travel funds are 
>> an issue.  Here, the only travel funds are what you generate on research 
>> grants, and since none are related to Python I cannot use them.  I need 
>> to be more creative.  :-)
>>     
>
> The PSF has a grant program, designed with people like you in mind.
>
> I don't know if we are going to have a pair programming clinic at
> Europython this year, but watch the Europython space and see what
> gets announced. http://www.europython.org/community  Europython has
> a grant program as well, and there was some talk of having the PSF
> possibly fund some people's travel to Europython.  
>
> <snip>
>
>   
>> -rich
>> enbody at cse.msu.edu
>>     
>
> Good luck, and I can write a whole lot more about this, but
> I suspect this is already long enough,
>
> Laura Creighton
>