On Fri, Jan 22, 2016 at 06:06:16PM -0500, Peter Teuben wrote: > The "annoying" thing about live coding I've seen happen a lot is the > typos. Although it's good to see it live, as your eyes read and think > along with the instructor, it becomes a nuisance if there are too many > typos that they have to redo.... I realized just now, and was testing > this, that you can also have a dual screen, one is the presentation mode > that the students see, the other what you see, you could cut and paste > them into the view the students see. Could be a nice > cheat.
I recommend against that. The problem is that seeing instructors cutting & pasting code will suggest to some that that's a good practice, which it is not. It's quite impossible to prevent learners from adopting practices they see. Personally, I usually tell a class early on that I'm quite rubbish at talking and typing at the same time, and that they'll see me both talking and typing nonsense. Then, the first times I mistype I take some time to explain what the shell / interpreter made of it and why we ended up with the result we see. Later, I'll increasingly tend to say "me messing up again, sorry" and correct my typo. "Digressing" into discussing errors has the benefit of demonstrating doing computing / coding by deducing from principles rather than by trial and error. I think that makes it well worth spending the time, considering the lengths of time I've spent fixing up code "developed" by prolonged practices of trial and error. So setting an example of invoking principles to resolve errors should generate a nice "return of investment" of the time put into this in the long run. Best regards, Jan > On 01/22/2016 03:56 PM, Timothée Poisot wrote: > > I think it depends on your feeling. I have 0 issues with doing live > > coding with no support, which involves failing to solve the problem on > > my first attempt about 95% of the time. > > > > Which I think it's fine, as I take it as an excuse to walk people > > through the "real" coding process -- we try something, mess it up, then > > try alternative things until it works. Outside of SWC context, I also > > received student feedback that said, essentially, that it makes > > instructors look "less impressive" (and I think it is a good thing). > > > > But some other times, I *do* keep a printout of the code next to me just > > in case. > > > > My 2c. > > > > t > > > > Andreas Mueller (22/01 15:51): > >> Hi. > >> > >> I'm new to SWC and I'm about to finish the instructor training. > >> I have a very basic question about presenting the material. > >> > >> I'll host a git workshop soon at my university (not branded as SWC but > >> using > >> the material). > >> Looking at the git workshop at the last scipy: > >> https://www.youtube.com/watch?v=hKFNPxxkbO0 > >> Azalee is going through slides and then doing live coding. > >> > >> The live coding is exactly the same as in the SWC material, but it's not on > >> the slides. > >> So I'm not sure where he gets the material from. Is it learned by heart or > >> does he have a printed out version next to him or somewhere else? > >> > >> Thanks! > >> > >> Andy > >> > >> _______________________________________________ > >> Discuss mailing list > >> [email protected] > >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org -- +- Jan T. Kim -------------------------------------------------------+ | email: [email protected] | | WWW: http://www.jtkim.dreamhosters.com/ | *-----=< hierarchical systems are for files, not for humans >=-----* _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
