Hi all, I'm coming up to speed teaching BJC/Snap! to a handful of high school seniors, in a school that is working with a 'hybrid' response to covid-19 -- alternate weeks remote and in-person, and in-person is masked, distanced, etc.
I'm finding it difficult to figure out logistically how to do pair programming under these conditions. Taking turns at the same keyboard, even being close enough to look at the same screen, is problematic. I've tried having remote students pair up on zoom and swap roles using 'Request Support' (i.e. give remote control of keyboard/mouse), but some students report that is not working.
Another approach is at swap points, students save/export and email each other links/xml, but this takes time to swap and creates a pile of projects per assignment that can lead to confusion.
What I think would be really great is if Snap! had a way to share with editing privileges. Most ideal would be live collaboration, both students could be manipulating the project simultaneously, but it would even be sufficient if students could both have the project open, the driver be working on it, and save, then the navigator re-opens and takes over as driver.
Any other ideas for best practices how to do pair programming in the era of covid19?
We do intend to implement sharing with editing privileges. That should happen fairly soon, by which I mean less than a year from now -- there are still too many burning issues to address.
Simultaneous editing is much harder to implement and we may or may not ever do it, especially since Zoom has sort of done it for us. Could you be more specific about how that isn't working for students?
But even with the best technological support, pair programming is not going to be easy. It doesn't work unless the partners are constantly talking with each other, and that's going to feel weird at six-foot distances. Zoom may be the answer to this, too; you just pretend the partners are in different rooms. Even so, unless you have enough headphones for everyone -- sterilized between classes -- it's going to be pretty loud in the classroom. That can actually feel good once you and students get used to it, but if there's another classroom next door, that teacher may have something to say about it.
My guess is that out in the real world nobody's doing this kind of pair programming now; instead each programmer works on a task alone, but gets a partner to review their work periodically. You might try something similar: each student works alone for half the class period, they they swap projects and critique each other's work. That'll be embarrassing for the students who lean on their partner to do all the thinking, but maybe they'll be persuaded to ask for help when needed.
Which raises the question of how you do your job while socially distant. Can you walk around the room looking over shoulders? Or do you initiate Zoom chats with individual students to look over their work and answer questions?
How zoom is not working? Not exactly sure, except one student said with the remote control he was not able to mouse/type his partner's computer. I haven't gotten to probe, it's either zoom's problem, or more likely operator error.
I had thought about in-classroom zoom. I'm not sure it would have to get too terribly loud, I'd say skip the headphones & mics altogether, use zoom for desktop sharing, and it would be like a buzzing classroom full of students working on a project. I'm lucky also, v. small school, only 5 students in this elective class (the odd number is really my biggest problem for pairing!)
As for me, it's not too bad as I'm only teaching this one tiny class as a side-project outside my day job. I am supposed to stay more distant from the students than they from each other, but I guess I do peek at their screens and get too close. I want to get to a point where the BJC/Snap! component of the course is almost all self-work, and I give them feedback and rework instructions after the fact.
bh I really appreciate everything you (and the team) have put into Snap! and the forums. I watched the video online of your final Berkeley lecture and loved that, and am interested to learn more about your hobby of teaching programming to elementary schoolers. Using Snap! I assume, but at simpler than BJC? Have you written about that somewhere?
Nah, that was in an after-school just-for-fun program, so I would just say "Here's how you click two blocks together. Go!" and let them do what they wanted. I used Scratch, because I figured that the benefit to kids of the Scratch user community outweighed the programming benefits of Snap!. (This was before our community site, but for elementary school kids I think I'd still choose their community over ours, partly because of our PG-13 experiment but also because they'd find more kids their age there.) Once a month or so I'd make them work on a challenge, like this one: https://scratch.mit.edu/projects/1101937/
By the way, while I'm logged into Scratch on another tab, here's the project I made to try to convince the Scratch Team that they should absorb our work into Scratch: https://scratch.mit.edu/projects/257694182/
Seventy Maxims of Maximally Effective Mercenaries, Maxim #21: Give a man a fish, feed him for a day. Take his fish away and tell him he's lucky just to be alive, and he'll figure out how to catch another one for you to take tomorrow.
Hi! I'm a middle school teacher for grades 5-8 and I have my students pair programming in both hybrid and distance learning. It's not the most ideal situation, but it has been good for our students socially to be working together.
I have students using Zoom (with headphones), two students per breakout room. The driver shares their screen. The navigator split screens with the instructions and zoom. They can use "annotate" if needed to help the driver. I build in the pair programming switches explicitly to their labs (they switch really often, every problem/block or so). When they switch they have to save, share, open and send the link to their partner. Their partner has to save and share. I really have to emphasize, "make sure the link has your username in it!"
I pick the pairs for the students based on their skill level and social inclinations and I switch them every lab. If a student ever gets ahead of their programming partner (on their own at home, or because pairs switch due to an absence) they are the navigator until their partner catches up.
It was a rough first couple of weeks and I still have students who get confused over the sharing of project links (this is so much more complicated than need be on Snap!...), but I figured that this was better than the alternative and I would say that it 90% works. For hybrid learning, I let them figure out what works for them (some students lucky enough to be next to each other just take off their mics), but there's always the whisper into your mic option that I tell them to use as their last resort (luckily all students are required to bring their own headphones).
All in all, they are pretty quick to figure out how to make it work and if you are very explicit about how and when to do the programming swaps (even down to the naming of the project), they'll teach each other how to optimize that process. The most important point is to tell them to look for their username and project name in the url.
Dedicate time at the end of class to making them turn in links that MUST have their own username and project name in the url (this took 15 minutes the first few times). I did this with my 5th and 6th graders and they are pair programming swapping like pros. I didn't do this with my 7th and 8th graders, and they're struggling much more.
Thx for the feedback. You are experiencing exactly the complications I was expecting with remote swapping by sharing and emailing links. Do you recommend them to Save As... the same name every time to avoid confusion between versions (but risk stomping bad data on top of good)? Or increment version numbers to try to keep track (but end up with proliferation? They can always clean out non-final versions at the end of every project)
I've got 5 motivated seniors, you've got class(es?) full of middle schoolers -- good job getting this to work!!
They can use "annotate" if needed to help the driver.
That's a great tip, thanks! I will try that out and see if it will be helpful to my students
Hi! All the credit goes to our wonderful 7/8th graders that went through many little experiments to tune the process. They were champs!
In the first couple of classes I had very explicit instructions for switching which included using the “save as” + “open”. As they got used to saving and sharing, I let them do whatever worked for them.
Rough example of the instructions for the first few labs:
do some work
Driver 1:
save your work: file > save as (lab # + your name)
do some work
Driver 1:
share your work: file > open > click on project > click share > click open (unnecessary but good habit)
check the link has your username and project name
copy link and send to navigator
Switch
Driver 2:
open link
save a copy: file > save as (lab # + your name)
check the link (it should be still your partner's username)
open your copy: file > open > click on project
check the link (it should have no one's username because it's your unshared copy)
do some work
Driver 2:
share your work: file > open > click on project > click share > click open
check the link has your username and project name
send the link to your partner
switch
Driver 1:
open link
save over your copy: file > save as > click on (lab # + your name)
check the link (it should be still your partner's username)
open your copy: file > open > click on (lab # + your name) > click open
check the link has your username and project name
Both: Submit YOUR link (url doesn't have your username? file, open and share!)
Seems crazy, but just it works if you break it down and make it super guided in the instructions. The reality is they just have to do it a bunch to get it.
I definitely will talk to them about saving multiple versions when we get to bigger projects. But for now, I’ve been less prescriptive and letting them name things however they want to. Instead, they have to redo their work if they lose it/saved over it. I do keep the labs short and submissions incremental to make it not too horrible if they lose work. (However redoing unsaved work has given some of them the unintended benefit of extra practice and reinforcement).
My advice? Start with small labs/assignments that focus on switching and submitting. Have stringent requirements for submissions (both partners must submit their own links with their username in the url, you can only submit one link and it must have all the code) and they’ll figure out the system that works for them!
To be honest, it feels like there is a bug in this process that should be fixed. Right now, if you open a shared link and you simply hit "save" it saves a copy in your account with the same name. If you happen to have a project with the same name, it overrides it without asking you...
I think the "save" option should be disabled when you are opening a shared project from someone else. It should be a forced "save as" so you are aware of the fact that it is an override.
Furthermore, "save as" should then automatically trigger a redirect to clear the url or load the new url. Right now, you "save as" and it maintains the same link, which still points to the originally shared project even though you now technically have a different project open.
We intend to set up a way to have multiple people with write access to the same copy of a project. That will fix a lot of this hassle. Don't hold your breath; most of our small staff have day jobs. But we know it's something teachers need urgently.
P.S. It just occurs to me that in a hybrid class, pairing physical kids with virtual kids should help the problem about virtual kids' attendance falling off.
I'm all remote with all remote students in high school and we've just started pair programming. I emphasize the conversation more than the actual saving. They either build together by the end of the class period or send a shared link to each other in the chat or by email according to each group. They say they like slightly larger groups remote which makes sense to me so I've been doing 4 and 5 so there are 2 drivers and 2 navigators. I require cameras on, unmute, one shared screen at least and conversation. I like this page of important aspects of pair programming... they will figure out how to get an
"answer" but the experience is what I want to develop.
No great program was ever built by one programmer alone.
Interesting, I can imagine taking that even further, and having everybody on the team building the 'same' program, and the group talking themselves through it. Take turns sharing screens, and students would get a view of different choices (block layout, variable naming, etc) and talk about that, why the choices were made, why differences matter or not.
Is the essence of pair programming drained if everybody is driver and everybody is navigator?
This is a slight exaggeration. Ghostscript, for example, was all Peter Deutsch, although later it was added to by other people. But for a long time it was just Peter. Emacs and gcc were originally just Richard Stallman. And, umm, Snap! is still almost entirely Jens Mönig. Linux is now a huge enterprise with maybe hundreds of programmers, but initially it was all Linus Torvalds (while he was a college student). Many of the microcomputer Logo implementations were all Brian Silverman.
I think it's fair to say that great programs eventually attract volunteers to improve it. But if the project started with a group of volunteers it would probably never have gotten off the ground.
There are a few examples with two programmers, such as Unix, written by Ken Thompson and Dennis Ritchie. There are also pairs like Bob Frankston and Dan Bricklin, the inventors of VisiCalc, the first spreadsheet program, in which Bricklin had the original idea but Frankston did all the programming.
I think it's fair to say that great programs eventually attract volunteers to improve it. But if the project started with a group of volunteers it would probably never have gotten off the ground.
I recently learned of the concept of BDFL=Benevolent Dictator For Life, which (it was explained to me) is why Python is thriving, but Perl is floundering.