[Edu-sig] introduction

[Laura Creighton]

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