Hi Peter! (I sent this directly to you, now replying to list...)
On Fri, Jan 5, 2018 at 10:55 PM, Peter Hoyt <[email protected]> wrote: > I recently was helping in a SWC workshop, with a (beginner) learner who > got lost. > Instead of taking over the learners keyboard, I talked her through the > process. > Not sure if you saw a thread Belinda started on this topic in November. The subject line was "On not touching people's devices", there are some thoughts, suggestions, and resources in it: http://lists.software-carpentry.org/pipermail/discuss/2017-November/thread. html#5609 Even though I tried to be quiet, this turned out to be VERY distracting to > nearby learners (and they let me know it), and it's understandable. Has > anyone come up with a strategy to deal with this? For example if you could > grab the laptop and move to an empty spot in the back of the room where > learners can be talked to, without disturbing others? This seems > distracting also, and would only make the learner fall farther behind. > This scenarios resonates with me: I'm loud, my voice carries, and I end up having less control over my volume the more caffeinated, excited, or sleep deprived I am, so I've definitely run into this before (which unfortunately also means it has likely happened even more when those around were to polite to tell me to pipe down). It's tough and very situation dependent - if it doesn't block them from continuing to participate, you can suggested putting the issue aside for now and offer to help during the next break. Another way is to get on a synchronous communication channel - (be it IRC, slack, or etherpad), and try to solve it that way. The advantage of doing that in the channel used by the workshop is that other helpers/instructors/learners might face the same issue and will benefit form the instruction, or have a clue about how to proceed. It also allows the person to context switch a little bit gentler, and perhaps copy-paste commands as opposed to having to type them out from your phonetic incantations like "arr em space minus eff arr space dot slash data enter". I've also written out commands on a piece of paper and handed it over. Now having said that, as you point out there is a tension between wanting to provide full context (what's happening, why, and enumerating the different paths towards resolution) and getting to a resolution. But sometimes, you're just going to get an impossible situation - I recall a hardware failure - computer freezing and refusing to boot mid-workshop one time. The owner said that it was known to be a flaky laptop, and we tried switching bios settings and had a bootable USB drive with Debian on it that we tried to conjure new life into that machine, which partially worked but in the end there was little we could do about it - the machine kept freezing, we had to admit defeat and change our expectations and our strategy for the remainder of the day. -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
