Friday, June 13, 2014

One pedagogical argument is that pairing should be restricted to just pairs. By having only two people in the pairing session we increase the likelihood that both are doing active work. Others may benefit from observing, but they are also reducing the pool of other possible pair partners, and in the case where students are pairing on homeworks that are being assessed, there might be an argument to suggest that observers are freeloading.

However, taking an active part in a pair is very intimidating for many and so it's a big advantage in some ways if random pairing sessions are visible for observation and/or some degree of interaction with a wider group of learners.

There is a tension between the desire for each individual learner to operate in the manner that feels most comfortable at any given time (working solo, working actively in a pair, observing a pair etc.) and the desire to assess learner's abilities. If we were only concerned with promoting learning, then we would not necessarily impose restrictions on observers, although there is the further case of where learners would like to pair, but would like to restrict who is observing for privacy reasons. Privacy reasons are unclear to the current author, but seem to revolve around the fear of aspects of one's personality being displayed for others to judge? Online remote pair programming does not require that people display video of themselves, or even necessarily any audio, but still one's typing is exposed in real time, and one's decisions about what to type next, what code to create, are being exposed, in the much the same way that they might be in an oral exam, and many people are intimidated by interviews and oral exams. Superficially this is related to a fear that one will be judged as not having made the grade, but the author would love to hear insights from others on this.

Ideally learning situations such as remote pairing should not revolve around judgement of each others abilities, and provide a supportative environment for learning, but naturally all learners will be making judgements of each other (and themselves), such as relating to their partners language ability, coding ability, and so forth. Some learners are in a hurry and may feel that they don't have time to be pairing with someone they consider as being less skilled in areas they want to improve in.

The author would suggest that the idea of placing learners on a linear spectrum of ability does not make much sense. Everyone's understanding and skills are a complex multidimensional entity. For example one individual may be very confident in Ruby String manipulation, but much less confident as regards OOP and another learner's understanding/confident may be exactly the opposite. As regards coding one's number of years programming is often considered a guide towards "ability level" but still there is no clear linear relationship, and learners might well be advised to be patient and discover what they can learn from every possible pair partner.

Having all pairing sessions recorded is arguably a good move since it allows analysis of the pairing, ensure that any disputes about behaviour can be resolved with relation to a video of what actually happened. Knowledge that one is being recorded (if not directly observed) serves as an incentive to behave more congenially. The downside of recording is that it will increase the nervousness of some, and might prevent them from participating in the pairing session as actively as they would like.

Assuming that one can host pairing sessions and drop 2 or more people into them, and record them; the question arises about the best mechanism of pairing people up. One of the key issues seems to be people's shifting schedules and being ready to pair. If you add your name to a list of people wanting to pair, will you be available at the time someone else is ready?

If you have some mechanism for checking that someone is actually looking at a given page you could indeed have a list of people ready to go, although people may still be AFK (away from keyboard). It's an interesting question about whether people should be asked to register their interests for a pairing session, e.g. Homework 2, Project X, or open to suggestions. Should you have a single list of everyone ready for impromptu pairing, or should their be some set of lists divided up at some granularity - it seems like that depends on the numbers involved. In the first instance perhaps one should just have a single list, until one demonstrates the need for more ...

There is also the question about whether one should have a list of ongoing sessions that others can browse and then join. In the open source project case it seems the answer should be a resounding yes. In the student case it seems we are caught between the desire to showcase the system running in progress (and allowing others to learn by observing), and the desire to afford students with additional privacy, and reduce perceptions of freeloading.

If one is offering a service for free then one can argue that participants have a degree of obligation to share what they are doing, i.e. contributing back, although of course the flip side is that if participants feel uncomfortable then they will just not participate. It seems reasonable to suggest that a premium version of the system might allow privacy; since participants are contributing to the system by paying for it.

Finally there is the question of how to effectively scaffold pairing sessions with novice pair partners. One can imagine step by step pairing walkthroughs, but it is currently unclear what the best mechanism would be to insert these into a pairing session? Perhaps a cloud9/nitrous session where the computer would prompt the pair partners to switch roles and have certain sorts of discussions at certain times. A human coach can scaffold that with some degree of skill - how much of it can we automate?