Friday, June 13, 2014

Thoughts about pair roulette, pairing in MOOC

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?

5 comments:

If we're talking about remote pairing, it's a crap shoot. That isn't to say that the idea's posted aren't valid ones. I completely agree that some people are better suited for driving, some better suited for observing. As far as people not wanting to be judged, that's a personal thing. Everything is a learning experience, and I've been blessed with an instructor that did as much as he could to help develop developers to stray from their comfort zones. Ultimately, in my opinion, development is still an infant, and every changing. Things will change all the time.

Sam, good points. - I haven't watched many pairing videos for the homeworks on the events page (https://plus.google.com/communities/101007836695292894562/events). If I were to watch a video of other students working out the solutions for homeworks I haven't done yet, I feel that I'd be cheating myself by not struggling through the process of figuring out a solution myself. Maybe I'm doing myself a disservice, maybe struggling to figure it out is inefficient... it can be maddeningly frustrating at times. There are ethical considerations (i.e. is it cheating?), as well as learning/pedagogy effectiveness. Maybe the benefits of watching others solving the problems outweigh the negatives. In that case, users should be able to rate videos so that later users can find the best video solutions for homeworks and other projects.

- I like to go over the homework first on my own to get a good idea of how I'm going to solve it before I pair up. If both pair partners are clueless, then the session can be unproductive and uncomfortable. I think that this is an inherent problem/risk with pair programming for students. Also, I'd be embarrassed to have a video online of me struggling to find a solution.

- I'd like to read more about potential partners before pairing up. Google Plus has that capability, but most people don't tell about work experience or programming interests on G+.

- To remedy AFK, the software could send a text to the user in the queue who has been requested as a partner. Also, I like the idea of a time-limited queue, e.g. you're removed from the queue after 2 hours if you haven't been paired by then.

- as a student in 169.x, I have a desire to pair on the assignment that's coming due, and only on that assignment. So I see a need to specify the 'project'. However, that can co-exist with an "open for anything" option.

Great comments. I would add though that I think just because on a Tuesday somebody feels more like observing than driving, that that doesn't mean that they can't feel like driving on the next day, or the next week; and of course ideally drivers and observers are swapping roles **every** 15 minutes ...

interesting points, e.g. "I feel that I'd be cheating myself by not struggling through the process of figuring out a solution myself", but of course ultimately how we learn is up to each of us individually. If on one day I choose to try and work through something myself, and on another day I watch how someone else solves a problem, isn't it ultimately up to me how I structure my learning process?

I think even when both partners are clueless you can have a productive pairing session - I would call it productive exploration of the problem space. You likely won't make as much progress as if both parties have been carefully reading up on everything, but I would encourage reading the docs together as much as I would encourage writing code together.

I think people shouldn't be embarrassed about having a video online of themselves struggling to find a solution. I have 100's of videos of me online with me struggling to find solutions for Agile Ventures projects. I think the key thing for every aspiring developer is to learn how to **not** be embarrassed about displaying their struggles. This is the critical skill - you have to be able to admit honestly to not knowing something and work with whoever is on hand to figure out together what you have to do. I know that our current culture/education system teaches us to behave in this insane frightened manner, but we have to break out of that if we are really going to excel and have fun building cool stuff.

Reading more about potential partners could be cool - but that could also be seen as a privacy invasion, and there is the danger of judging a book by its cover, no?

Text messages are a great extra feature but I don't think they solve the fundamental problem - we need the simplest possible MVP, and ideally things like many people wanting to pair on an upcoming assignment will just fall out of our lovely simplistic design. In general we want to solve problems by removing components rather than adding them to avoid the complexity explosion which kills most projects ...

You've given me a lot to think about. Do you have more material on your vision of education? Or a favorite paper on this topic?- "how we learn is up to each of us individually". I learn best by example, monkey see/ monkey do... more specifically, I learn best by taking an existing well-designed working program and then modifying it to do something slightly different, or extend it, using the same patterns that are already in the code. Watching videos of other programmers is still relatively new to me, but I agree that there's value. I'd like to see more sample code covering different apps (and sample code videos) in the 169.x series, perhaps some of the AV projects could serve this role.- I think that there should be some clarification from you & the other instructors about what is allowed (i.e. honor code) and in fact encouraged... e.g., simply using solutions you happen to find online is not allowed, but watching programmers work through the solution online (or even reading a solution online but not copying the code) then following their approach is encouraged. - Yesterday I pair programmed for the OOB homework. I set up a google event for 2 hours in the future, but then when the time came, nobody had joined. So I went into the chat room and posted the event with a plea for a partner, then I had a partner... I assume from the chat room posting, but I'm not sure. Someone else tried to join then left later, perhaps because I already had a partner but he never said anything so I don't know. I think that online chat would be a useful feature for this pairing solution.

- also, after my initial partner left, I had a second silent partner named Moises... he had already done the project, but he texted me minimal advice at each point when I got stuck and that was a wonderful experience.