+1 to all of the above -- it's also incredibly important for the students to see "the experts" making mistakes and correcting them. It also provides the attention grabbing "live demo/car wreck" feeling - students pay attention to me to catch my typos and see me fail.
--titus On Sat, Jan 23, 2016 at 10:32:53AM -0500, Marianne Corvellec wrote: > Hi all, > > I believe one of the greatest things about SWC is that you are *not > alone* teaching and you are not lecturing. So you don't need to > cheat. The other instructor in the room and/or helpers could/should > help you with typos as they come along. And, of course, you > could/should return the favour. :) > > Cheers, > Marianne > > On Sat, Jan 23, 2016 at 9:43 AM, Sarah Mount <[email protected]> wrote: > > Welcome Andreas! > > > > On Fri, Jan 22, 2016 at 8:51 PM, Andreas Mueller <[email protected]> wrote: > >> > >> 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? > >> > > > > > > It's really entirely up to you, but here's some anecdata for you, which may > > or may not be useful... > > > > Back when I was teaching introductory programming, I used to write out every > > examples I wanted to go through with my students before each lecture, > > usually the day before. I would put all these programs in a text file and > > print them out. When I went to the lecture I'd place the print out face-down > > on the lectern (so I couldn't see it) and go through each example etc. in > > turn. For some reason writing the programs out first meant I remembered them > > pretty well, but having this "safety net", in case I got completely lost, > > made me feel a lot better. I think I only referred to a print out about once > > in a decade. The safety net wasn't really there in case I couldn't make a > > program work, it was there in case I forgot which example came next or lost > > my train of thought. > > > > When I went through the example programs (and this is a little different to > > SWC) I would approach them in a "Socratic" style, i.e. by getting the > > students to design each program by answering my questions. So, I would say > > things like "We want the turtle to draw a square, what should it do first?" > > "How far should it travel?" "What next?" "Can we write that in a few less > > lines of code?" (hint for introducing iteration), etc. This way, the code > > from each lecture would be different to the code I had written the night > > before, and sometimes radically so, which meant I had to put the student-led > > code up on the VLE after class. When we wrote "Python for Rookies", the > > intention was that each chapter of the book would be an expanded version of > > these lectures, with extra material and examples. Some chapters (like the > > one on recursion) came out almost exactly as we had taught them, although > > that book is pretty outdated now. > > > > The first time I did this sort of thing I was taking a Java class who had > > already had most of a year of being taught with OHP slides (those were the > > days). On my first program, which was probably trivially simple, I forgot > > some semi-colon or bracket or something, and got a compiler error. Some poor > > kid said "OH, so YOU get those error messages too" -- he'd spent most of a > > year genuinely believing that "real" programmers don't make mistakes. This > > convinced me never to present pre-prepared solutions to an introductory > > class again. I realised that the most useful thing I could teach my students > > was how I think about code and writing programs. That might still not be > > very good (maybe I am a terrible programmer, how would I ever know?!) but > > unless one of you natural science people can invent a telepathy machine, I > > think it is the best I can manage. > > > > Hope you are enjoying the training! > > > > Sarah > > > > > > > > -- > > Dr. Sarah Mount, Research Associate, King's College London: > > http://soft-dev.org/ > > Fellow of the Software Sustainability Institute: http://software.ac.uk/ > > twitter: @snim2 > > > > _______________________________________________ > > 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 -- C. Titus Brown, [email protected] _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
