Fifth Meeting for Round 12

We had three lively discussions this week, and lots of good feedback on the online teaching demos. Over the next two weeks:

1. Make sure you have read Chapter 4 of How Learning Works
2. Comment on https://github.com/swcarpentry/training-course/issues/445 and/or http://swcarpentry.github.io/training-course/2015/04/Round12Talkpage/
3. Do another round of online practice teaching:
   • stay in the same groups
   • pick a different part of our standard lessons to teach
   • teach for 3 minutes rather than 5
     • teach as if you were in the middle of a larger lesson (don’t bother with introductions or wrap-up)
   • record your lesson and post the video on YouTube, Vimeo, or a similar site
   • get feedback while you are teaching (but don’t include that in your video)
   • watch some other people’s videos and leave them comments
   • wait at least 24 hours and then watch your own video and give yourself feedback
4. Add a short blog post to the _submissions/round-12/4 directory with a link to your video. Your file should be called yyyy-mm-dd-your-name.md as usual; the permalink should be /2015/04/your-name-video/ (please remember the closing slash), and the two tags should be Practice Teaching and Video. Your blog post should include:
   • one or two sentences about your chosen topic
   • a link to your video
   • any feedback from your teammates that you want to include

So how do you record yourself?

• If you’re on a Mac, open Quicktime, select “File… New Screen Recording”, click the little down-arrow beside the “Start Recording” button to select the audio input, and away you go.
• On Windows, you can use Microsoft ScreenRecorder or Open Broadcaster Software.
• On Linux - well, on Ubuntu, you can use SimpleScreenRecorder.

There are also free cross-platform tools, like Freeseer, but if you’re going to be creating a lot of screencasts, Camtasia Studio is worth buying.

Note: we’re asking you to record a live teaching session rather than making a screencast on your own because we have found in the past that many people will spend hours doing one take after another when asked to do the latter. Your teammates are unlikely to sit through your presentation twenty times, so recording a live session is a sneaky way to prevent you from putting in more time than you should.

Questions

• What did you learn about your own teaching from your practice session?
• What’s different about teaching online (compared to teaching in the room)?
• On a scale of 0-10, how comfortable do you *now* feel with Git and GitHub?
• What could/should we require people to know before enrolling in this class, and how can we require it without scaring people away?

10:00 Eastern

• Laurie Baker (University of Glasgow)
  • Stumbling/flow. Adding an introduction and going over learning outcomes.
  • Teaching online you need to make more of an effort to get feedback because you can’t always see whether someone is nodding/following along. Regular check ins would be good.
  • 4, the help session was great. I’m learning lots and they recommended some good resources. I see becoming more familiar with these tools through the homework as a big plus.
  • Encourage people to sign up in pairs for teaching. Having a physical community could help people work through the challenges. Have a few short exercises with a guide to complete before starting the course. Would be a good test to see if people have the time, and hopefully would teach them a few of the work flows before starting.
• Konrad Forstner (University of Würzburg)
  • I stumble in one of the discussed issue - previous knowledge (cut & paste in gui tools vs. cut & paste in the Shell) - should have taken care of this.
  • Not too much difference. Little bit less body language to interpret.
  • Git + Github: 9
  • Basic understanding of markup languages and programming;
• Owen Stephens (Owen Stephens Consulting)
  • That I could deliver an understandable lesson online, but that I didn’t do things when teaching pre-packaged material that I might naturally do if teaching my own material
  • Was v hard to know how people were following along - stuff I would try to pick up by observing the room when face-to-face
  • Git/Github: 7
  • I think requirements can be minimal, but some things need clearly laying out at the start. Attending a course as a pupil as a recommendation?
• Richard Tomsett (OIST)
  • I am still a bit nervous even when just trying to teach a lesson to two supportive colleagues! Needed to present learning outcomes at start.
  • Can’t see people’s reactions for instant feedback, so you have to make sure you’re definitely explaining everything well and stop to ask if everyone is following along OK (I forgot to do this)
  • 7.5
  • I’m not sure what prerequisites should be there… perhaps the first assignment should be to do a basic github commit of a markdown file, and providing links to teaching videos for the basics of each? Using github for the blog is a bit of a pain vs WordPress but as you say it allows us all to practice with github in a group context.
• Filipe Fernandes (UFBA)
  • I learned that, without a proper background/context, even simple lessons can be challenging.
  • The main difference for me is the detachment from the students.
  • Git+GitHub: 8
  • Not sure… As you said, people are learning Git as the training goes.
• Malvika Sharan (University of Wurzburg)
  • Preparation is the key, else i tend to get nervous
  • ‘body-language factor’ is missing from both teacher and students in online teaching, whereas in the classroom you can read the blank faces or enthusiasm and modulate your teaching methods accordingly
  • 7.5
  • Technically, I think its good to have basic programming skill (which I was asked before I got included to the training course)
    • Establish a virtual group (kind of facebook groups) so we get comfortable with each other and allow the discussion and group-support
• Sue McClatchy (The Jackson Laboratory)
  • I learned that I’m easily rattled when things don’t go smoothly.
  • Online teaching is difficult because you don’t have the non-verbal feedback that you normally would have when you’re in the same room. It forces you to become more interactive and attuned to your audience, just to make sure they’re still with you.
  • I taught the Git add-modify-commit cycle lesson because I didn’t understand it and felt that teaching it would be the best way to learn. I’m on a scale of 2 for comfort now.
  • People must have a sincere desire to learn and to teach. One of the best ways to learn a new topic is to teach it. It’s trial-by-fire, but it works. Teaching is inherently messy and requires much practice. Your first lesson out of the gate is going to be messy, uncomfortable, or disjointed, whether or not you have the background in the topic. Practice makes perfect. Empathy and honesty with your students are both important. If you don’t know, say it.
• Simon Fraser (Sanger Institute)
  • I need to plan more and have more organised thoughts for getting information across
  • It’s very easy to ramble and not pay attention to the students when you’re teaching online - must be more active in maintaining the relationship
  • GitHub familiarity: 7-8
  • Perhaps the start of the course could be covering git / markdown / etc, before the ‘real’ course starts
• Sarah Mount (University of Wolverhampton)
  • pacing not quite right,
  • no / little feedback from learners
  • 7-8
  • perhaps a way forward is to have instructor trainings for people who have taught the content elsewhere before or already collaborate on GitHub, and a different track for people who are still learning
• John Constable (Sanger Institute)
  • Timing the session is hard, even with repeated practice, found lack of context hard
  • 1-2-1 OK (two people so can teach using video camera, but lack of social cues really hard. I did no feedback with my student. :-(
  • 5 - I can do what I need to (just), but rebasing still scares me.. :-)
  • Interactive tutorials to give them an easy way to fail and try the skills, e.g. https://try.github.io/levels/1/challenges/1 for git but its not a technical issue; they have to want to teach.
• Donna Henderson (University of Oxford)
  • I notice my own mistakes more than the ‘students’ do; also, it’s difficult to speak and type at the same time
  • online you can’t use the students’ facial expressions to tell if they’re following
  • 7
  • Maybe don’t have requirements, but suggest people look into github and markdown beforehand
• Daiva Nielsen (University of Toronto)
  • I think I teach a bit too fast. I should slow down and elaborate on points more.
  • You can’t see students’ faces, so it’s hard to know if the class is following you/paying attention/lost etc.
  • 7 - I did a tutorial with Filipe and that was very helpful.
  • I think students should at least know how to use markdown. We could probably have an online resource to introduce people to markdown. I think it’s ok if they aren’t too familiar with Git/GitHub, but having an interactive tutorial they should complete would be helpful.
• Kim Moir
  • preparation is important so speech is smooth. As an aside, I took a R course recently on cousera and the professor did not use live coding. Seeing the live coding the person in my SC group did for R was much much better than just slides.
  • can’t walk over to someone’s computer and help them directly. Feedback is hard to see because you can’t see everyone.
  • 9/10
  • Maybe go through the software carpentry git material first so they have that background
• Daniel Wheeler (NIST)
  • Speech patterns need improvement
  • No immediate feedback
  • 8
  • Attend a software carpentry course as a student – self assessment – a few years of experience in one part of the curriculum either scripting – software engineering or sys admin of some sort, not all – limit the numbers so it’s easier to support everyone
• Javier Garcia-Algarra (UPM)
  • I had to rehearse several times to fit the lesson in 5 minutes
  • We had a lot of problems to set up the online session (50 minutes !)
  • Git: 7
  • Perhaps a short assesment test
• Phil Rosenfield (University of Padova)
  • That when I narrorate what I am doing, there is not necessarily a direct match between what I say and what I do.
  • Felt like I was talking to my laptop like a crazy person.
  • 9/10
  • I don’t think a list of pre-reqs in necessary – especially if there is something like what happened this time with git/github/markdown. I think separating the cog. psych. from the command line and other things taught in workshops is good for the instructor course. If it were all up to me, I’d rope people in with this course as is, and use SWC volunteers in – a formal manner – to help out with “pre-reqs”
  • I think we should rely on self-confidence in X pre-req. That’s what’s important when teaching, and they can sign up for the tutor lessons if needed.
• Remi Daigle (University of Toronto)
  • I have no idea how much “5 minutes” is… can’t cover much in that short time frame
  • It’s a bit more difficult, no visual cues from peoples faces
  • Git:Github 8/10
  • Have “self-serve” tutorials for people to brush up or build on skills to get them to the level they need to be. Content would be tailored to the level of SWC instructor basic needs
• Arliss Collins (Mozilla Science Lab)
  • 5 mins is a short time and if something goes wrong I need to have a way to keep the audience engaged while I fix the problem.
  • you lose the visual feedback that you get from the audiences faces
  • 6 - working on my PR for the past assignment completely on my own following my Git tutorial with Filipe (thank you again) I made a lot of progress on my understanding about remotes and getting them all up-to-date.
  • the basics on how to do a PR in Git if it is going to be the primary way to submit assignments and then if students don’t have this supply a step-by-step cheatsheet with explicit examples plus access to help.
• Pawel Pomorski (University of Waterloo)
  • I still say “obviously” and “just do ..”
  • online there is no immediate feedback from students, so it’s hard to pace oneself
  • git/github 8
  • requirement should be expertise to teach one of the lessons from our material well
  • as Git is required to participate in the course, potential participants would be advised to go through our Git lesson before participating
  • make sure it’s made clear to newbies that git is HARD
• Amy Boyle (Washington State University Vancouver)
  • I’m not as great at winging it as I thought. I need to practice what I am going to say, not just read over the material.
  • Feedback from students is harder without being able to see them in person
  • git 8/10
  • Have material people can work through to become eligible, have people post on github some simple exercise(s) to show that they have been through the material. Bootcamp before the teaching course for those that need it.
• Hugues Fontenelle (Oslo University Hospital, Norway)
  • Hard to type and talk at the same time and avoiding the silence/hmms. Some notes would have been useful.
  • First time teaching online; little experience live. But not seeing the students means no feedback, no visual cues as to whether they understand, etc
  • 7/10. I still need to think, and I’d better study the inner workings of git
  • Are we learning how to teach, or to be experts at Git/Python/shell/SQL/Matlab/etc ? I think it’s okay to know “only” one thing or two. After all, we’re not alone teaching during the workshop. For instance I can just teach what I feel comfortable at (python), and learn while a colleague is teaching (shell). Whatever else is bonus.
• Narayanan Raghupathy
  • I found it difficult to teach something just 5 mins and still be meaningful. Thought using tab completion will be a cool trick for the new comers while teaching, but found it did not help to teach slow.
  • the trouble with online teaching is that I had no clue whether whatever I said made sense or not.
  • github comfort level : 6/10. , more comfortable even though there is a lot to learn
  • I think the pre-requisite should be willingness to learn any missing piece(s).
• Arvind Sundaram (Norwegian Sequencing Centre)
  • It was difficult to teach to a ‘computer screen’. Also, with more practice, it should be able to teach better.
  • Feedback from students was missing. It was also difficult to get within 5 mins.
  • github - 5 on 10. But I am able to use the site to fill in necessary information.
  • I fell that there should be no prerequisites to join the course. If there are any, then the course will fail to achieve its goal of providing basic computing skills to all.
• Jessica Gallinger (University of Saskatchewan)
  • Preparation is important
  • Less anxiety-producing because students see my screen (and not my face). I can read from my notes and that’s OK.
  • 2/10
  • Nothing – let people filter themselves out
• Joseph Long (Space Telescope Science Institute)
  • I learned that I have a tendency to rewrite code when I use the notebook, which makes things disappear that learners may want to look back at. That’s something I should change, perhaps by using the IPython REPL instead.
  • I really enjoyed the teaching exercise, probably most out of all the exercises so far. Definitely the idea of keeping things onscreen is new for online teaching, but I think it would help me in-person as well.
  • I don’t feel like my git or github knowledge has changed much… I’m still just a little past the novice level, but I was able to add blog posts.
  • I do feel like there should be more communication about the technical skill prerequisites, but I’m still mulling over what that would look like. My friend is learning to be a teacher of English to speakers of other languages, and we were connecting on this. I think sometimes people who haven’t totally mastered the material have the best appreciation of how useful it is.

15:00 Eastern

• Laura Graham (University of Nottingham)
  • Good: pace, set objectives at the beginning of the lesson, bad: need to think more about the key components and make sure everything is explained/defined.
  • It was less nervewracking because I couldn’t see the (bored?) faces I was teaching to - something I find offputting in the classroom, I think that on the minus side though that meant I couldn’t adapt what I was doing by gauging how much was getting across. Also: technical difficulties caused a bit of an issue!
  • 8/10
  • I think that rather than requirements, there should perhaps be some pre-instructor training practice material to work through (perhaps putting up a blog post using git/github). Also for participants to have working knowledge of at least one of the things that would be taught as part of a SWC session.
• Sarah Stevens (University of Wisconsin - Madison)
  • I learned that it is sometimes difficult for students when I refer to items on my screen as being ‘here’
  • For me, I think in front of a bunch of eyes I’d be a lot more nervous. So I guess a big difference (plus or minus) is that you can see each other.
  • I feel about a 7 maybe
  • I think maybe an intro on how git works might be helpful. At least knowing a little has helped me a lot. While I’ve had difficulties not so many as if I had not been at all familiar with git/gitHub.
• Sarah W (college)
  • I missed our practice
  • see above
  • 4.5 - I can do what I need to do by remembering to look at my cheat sheet. Branches are still a topic I don’t quite get.
  • Maybe a brief session on git/githup/markdown. Maybe just include it in the beginning session?
• Matthew Bourque (Space Telescope Science Institute)
  • Live coding (as opposed to going through code that’s already there) enforces a good pace to the lesson for both the instructor and student.
  • You have to constantly be aware of possible technical issues with audio or video, which can be a bit annoying. Also, you can’t see the audience so its difficult to gauge their interest or reactions.
  • 7
  • “Highly recommend” the student to take a SWC bootcamp before taking the instructor training
• John Pormann (Duke University Libraries)
  • We haven’t gotten to our practice round yet (or I missed it?)
  • I’m awkwardly-comfortable with Git now … maybe a 5 out of 10
  • Knowledge of Git (or a good tutorial, maybe what Timothee just did this morning?); access to the book for pre-reading (to make the time-commitment a bit more spread out, if desired)
• Violet Zhang (University of Pennsylvania)
  • Probably should spend sometime explaining files and directory, and how are related. Also, explain what is an absolute path and a relative path.
    • Content is too advanced maybe. People might get lost.
  • not as much interaction between students and the teacher
  • 8
  • maybe give them a quiz containing some MCQs, and see if how the people are familiar with basic programming.
• Johan Hjelm (Technical University of Denmark)
  • I need to practice more and test the tools I am using, I got a bit lost when using an IPython Notebook, I wanted to explain what was in the namespace and forgot to use tools like %whos
  • It was different, no/little contact with the students while teaching, but I didn’t find it better or worse than teaching in front of a class
  • Git: learnt quite a bit the last two weeks, the tutorial and mentors were great, would say 6/10 now (but still don’t know how to use stash and rebase properly…) and can definitely recommend atom.io, the live markdown preview is excellent
  • maybe one could recommend that they have had a look at one or more of the SWC lessons (e.g. Git…) before taking the instructor course
• Kai Yang
  • The lesson I learned is that it might be conter-productive to use canned code segments for copy and paste. In addition, timing control is critical in real classroom situations.
  • In online teaching, the instructor is unable to observe students’ reactions. Also, there are heavy constraints on using variety of teaching tools.
  • 1. But I still like Perforce better.
  • Prerequisites: enthusiasm to teach and willingness to improve teaching skills.
• Francisco Navarro (University of Alicante, Spain)
  • That preparation is key
  • You won’t have technical issues (we lost 50 min in order to make the teleconference work properly) and the eye-contact or feedback is hard to obtain.
  • 6-7 (but last time I wrote the same… I was wrong then)
  • Well, the main issue here is GitHub. I was also enrolled in the last edition which used wordpress and this wasn’t a problem. I think that using GH is a good idea but I will encourage to prepare some materials showing how to use it with the GUI instead of command line. For markdown I will recommend atom.io (which also includes github)
• Adam Richie-Halford (University of Washington, Seattle, WA, USA)
  • I can go a little too quickly for some students. I do better when I have a script or outline.
  • Difficult to gauge student comprehension (limited feedback). I also felt limited by not being able to gesture.
  • Git: 8-9 (still some gaps in knowledge but I’m confident that I can figure stuff out)
  • I liked Vladimir’s suggestions:
    • can write a hello world program in python, R, or bash.
    • can clone a self-owned git repo from github, add a new file, commit, and push
    • can make the following directory structure using the console: ~/foo/bar/baz
  • Not scaring people away is the harder part and I suspect this mostly comes from the git requirement. Having people attend or help at an SWC training could work. Or we could require that people go through the lessons on their own, telling them that they don’t have to grok everything, just make a first pass through the material. I recognize that this may be a barrier to entry but I’m thinking about how Abrose et. al. discuss the important of reducing unnecessary cognitive load and I’m concerned that instructor trainees who are struggling with SWC content will not be able to learn about pedagogy at the same time.
• Catherine Devlin
  • I knew I go too fast. I found out that I still go too fast even when I specifically plan to slow down. Also got good suggestions about not using mysterious tools like `vim` when demoing to students.
  • Can’t see the students! OTOH no projector worries…
  • Git: now 8
  • No changes to suggest
• Derek Howard
  • How much time it would actually take to go through a small part of a lesson.
  • Teaching online makes it difficult to get instantaneous feedback. Hard to tell what the others think at that exact moment and whether they are genuinely following.
  • Git: 4? Enough to get assignments up, but at least I’m aware there is a whole lot more functionality that I haven’t learned to make use of.
• Jon Borrelli
  • While I did well at explaining some concepts, I need to think a little more before coming up with examples so as to not cause any additional confusion
  • Teaching online is harder you do not really get any instantaneous feedback (the looks on your student’s faces as you go through the lesson)
  • Git: 8 or 9
  • I think that either attending or helping with a workshop would be very helpful to most people who want to be an instructor, although I realize this may not be possible for all.
• Tessa Pierce (Scripps Institution of Oceanography, UCSD)
  • From teaching - It’s important to come up with the *right* examples to teach a concept.
  • Very difficult to teach without feedback from your “students”
  • Git: 6-7. We have our tutorial this afternoon, but Matt answered some of the questions I had, so I think I’m more comfortable with both git/github and markdown.
  • People should have attended a workshop or have similar knowledge level. A quick tutorial of github/markdown would be helpful before beginning the instructor training, though I think this issue will become less important as git/github becomes more widely used.
• John Moreau
  • I often use humor to defuse a tense situation. One participant rightly pointed out how sometimes jokes can make people feel worse. If I minimize or downplay a concept that someone hasn’t yet grasped, then they might become demotivated. The irony of this is not lost on me.
  • Also, I need to not let a technical glitch derail the lesson (or getting stressed)
  • You don’t get the same level of immediate feedback from people’s full body language. Also, I found myself doing hand gestures and then realized they were completely pointless because I was using screen share.
  • 6-7? I still have a couple of questions, but I think I can ask better questions now.
  • Everyone needs to have solid skills with one of the core languages (but maybe not Git\Github). They need to be able to speak intelligently about how they apply that language\skill set to their specific domain. Even if they present to an audience from outside of their domain, those personal examples make for compelling lessons.
    • I would love people to do a git-github unit as experiential learning. They experience teaching concepts like peer instruction and MCQs as feedback before learning about the pedagogical concepts.
    • Also we need to remember that different academic disciplines have different levels of cooperation and team lab work. In Economics, we don’t have as many co-authors or collaborators, so we don’t have as much opportunity to use collaboration tools.
• Andrew MacDonald
  • Think about my assumptions, and match my MCQs to the actual content of the lesson (very closely)
  • I miss having eye contact with my students. It felt like a monologue – it felt like it was going badly.
  • uh, it hasn’t really changed. maybe 6? I’d like to point out (unnecessarily) that skill w/ Jekyll != Github
  • I don’t think that we need to institute a core set of skills, necessarily. Perhaps new students should be sponsored/recommended/mentored by somebody.
• Karl Broman
  • Need to practice more
  • Found the isolated 5 min slice a bit hard, and not really knowing the “students”
  • Comfortable at git/github at 9
  • Not sure; ready to teach part of a SWC course? Have attended a course?

19:00 Eastern

• Belinda Weaver (QCIF/The University of Queensland, Australia)
  • That you need to practise a fair bit to be able to talk and code at the same time - I found it much more challenging than talking to a slide with a list of points. Also that it’s much harder teaching someone else’s material than teaching your own.
  • I really found it hard not looking people in the eye as I talked - I really try to engage with people as I go, so talking just to a screen and not seeing people’s faces was awful. I realise I really rely on audience feedback for things like pacing and testing whether people are ‘getting’ what I am saying.
  • Probably still around 4 or 5, but I feel comfortable asking for help now that I actually know SOMETHING. I feel I have made a lot of progress. Being able to get help on specific questions was really useful.Thanks to Trevor!
  • I think the key thing is finding out WHY they want to do it. Skills can be taught. Attitude is key. People who genuinely want to help researchers learn new skills and can imagine what the learner is struggling with will teach a whole lot better than someone with all the technical skills and knowledge in the world but zero empathy for someone else’s way of learning - the demotivation stories showed that.
    • P.S. I have posted two long comments on the GitHub page where this question was asked.
• Auriel Fournier (Arkansas Coop Unit/University of Arkansas)
  • Need to reiterate concepts to make sure that they stick
  • I feel less self concious since they just see th screen. But it was also harder to judge if everyone was following
  • After going through our SWC workshop I feel like a 8 or 9 in Git. finally have doing it in the shell down.
  • one subject area - and heavily suggest attending a workshop to learn the rest (I had V strong R skills, but no git/shell experience, now I’ve done a workshop and I feel with some practice I coudl teach git/shell)
• Jeremy Gray (University of Toronto)
  • Go too fast - without feedback I will rush to get to the end. I need to plan my pace out, and be happy with not finishing if I run out of time. Learned coding and talking use the same parts of my brain and I can’t do both efficiently without practice
  • Hard without feedback - no way to check student comprehension or interest
  • 8 - Still lacking some merge conflict/branching skills
  • Taking workshop/strong familiarity with at least 1 of the topics. This is mainly so people can see the level and scope of the course. Main prerequisite should be self motivation and self learning
• Meredith Durbin (Space Telescope Science Institute)
  • I learned that I need a good deal of rehearsal, or at least more rehearsal than I had done for this practice session; that seemed to be where most of my issues (pacing, stumbling) arose
  • Teaching online feels very isolating; no immediate feedback
  • Git/github: ~5
  • Working knowledge of at least 1 (and preferably more) standard SWC topic(s)
• Evgenij Belikov (Heriot-Watt University, Edinburgh)
  • I need to practice/prepare if using language not actively used by myself and having very limited time; counter to my feeling coding made me go slower which gave some time for participant to read the code and think about it; need to ask explicitly whether people are following ok or maybe use some intermittent quizzing
  • visual feedback was missing (did’t use the video to save bandwidth for sound)
  • git/github: 7
  • there should be no requirement apart from motivation; familiarity with topics is a nice-to-have, better not too much of an expert; also useful to participate in a workshop as participant before to have an idea how the workshops are run
• Luke Johnston (U of Toronto)
  • That a bit of prep before does help, tho sometimes there are issues that still come up and it can be frazzling to try to work thro them.
    • I need to keep in mind others programming skills and knowledge. I was teaching R, and the other two only knew Python and so I used ‘.’ in my function names and the others mentioned afterward that a dot has a certain meaning in Python. So I need to try to remember that the students/learners are truly novices and try to explain as much of what I am doing and why I am doing it.
    • I feel I stutter a bit/am disjointed while I talk. Especially when I don’t practice enough before hand.
  • It’s really hard to gauge whether the others were following along or not. I couldn’t adjust my teaching based on their reactions.
  • I rated myself fairly high before and I haven’t really changed since before this training
    • 9 or 10 / 10
  • That’s a difficult question… Maybe not require, but at least mention all the skills needed/desired.
  • Maybe a pre-requisite to take a tutorial on Markdown, YAML headers, basic concept behind Github Pages, and Git.
  • Just thought of this now, but how do people who are deaf participate in the training? ++ (mtb)
    • there are lots of speech-to-text devices that could be helpful… translates voices to words on a screen (that’s true, didn’t think of that.) :)
  • A working knowledge of some of SWC topics, given that we are teaching that.
• Horacio Vargas (Max Planck Institut)
  • The virtual classroom has to be defined in advance. I mean to whom are you going to give the class in order to prepare it properly or at least obtain some “on going” feedback. Rehearsing/ Practice is a key.
  • It took us more time to reach a virtual classroom than doing the exercise which also took important time from the exercise.
  • Git/GitHub: 5
  • I think it is important to know the main lines of the training to understand the goals of it. In my case I had the opportunity to follow closely an inspiring keynote talk at scipy that awaken my interest to enroll.
• Kyler Brown (U Chicago)
  • I had missed some technical details. Organizing a 5 minute lecture is much harder that 30 minutes.
  • Much less interaction online than in the classroom, closer to reciting a lecture in front of a mirror.
  • 7? - whatever is functionally adequate
  • I think it depends on how much you expect to teach the material itself within this class. So far, the class has not touched the material at all (except git). I think a series of simple questions that show the potential instructor has had some exposure to the material.
• Ben Weinstein (Stony Brook University)
  • I learned about pacing. Its not about being ‘fast’ or ‘slow’, but consistent. I kinda revved up as i went.
  • No facial expressions! Very challenging
  • 9, its still unclear to me how to post plots to github pages, but thats probably a higher level thing than needed here.
  • I think they should have a question. My experience is that people who know why they are attending are much more engaged. More than technical skills, i think having some goal that they can communicate is helpful, even if the instructors can’t meet it, we can harken to it. More important than knowing git push.
• Kathy Chung (U Toronto) – sorry everyone, lots of comments from me
  • Lessons from practise teaching:
    • I need to allow for more time to prep and time my talk.
    • Useful to state at beginning what goals of the lesson are and why
    • I need to stick to the script. I tend go off on a tangent or talk about additional details because something is interesting to me, and then I run out of time
  • Teaching Online:
    • need to prep in different way for live coding e.g. get the data files ready or in downloadable form for students; think ahead re. which windows I need to have open and available on my desktop for the lesson; what exactly I’m going to type.
    • can’t see students so less sense of their responses (whether they are bored, whether they are confused, etc.) and how I’m doing; have to ask and teach students to give feedback explicitly and regularly
    • the technical/logistical requirements (video conferencing, screen share, finding an etherpad, etc.) are an added layer of cognitive load
  • git/GitHub comfort level
    • 6
    • I still find the interface of GitHub way too busy and confusing and require more explanation. I’m still unclear how to resolve conflicts and work with branches.
    • The difficulty is that the our wonderful git/GitHub mentors/tutors/buddies still go too fast (expert/novice divide) or we are communicating online and run into logistic obstacles (screen share doesn’t work, sound is fuzzy, etc.) or time constraints. Often, learners have to read/hear/see things more than once or practise skills repeatedly and the quick, learn as we go, online tutoring context isn’t great in allowing for repetition, review, and practise.
  • pre-requisites for teaching training & scaring people off – I suspect there are two related but separate questions here: (1) a general question about level of existing skills before this class and (2) GitHub skills specifically
    • I took Greg at his word at the end of that June 2014 Toronto SWC workshop when he said you didn’t want experts; you wanted novices to help teach. I was/am a novice but game to learn (and bluff my way through some parts) and I was interested in teaching, so I signed up. Of course, everyone has different definitions of what “novice” means and future invitations to teaching training may define “novice” more clearly. This whole discussion is about that.
    • balancing act: you want a certain degree of expertise/familiarity *using* Python, (git, R, SQL, etc) in order to teach with confidence and answer questions adequately but you want enough of the novice mind to not skip over skills/knowledge which are automatic for experts
    • what are goals of TT or priorities: teaching skills OR technical coding skills (because TT lessons focus on teaching)
    • Maybe you need team instructional design? Novices AND experts together reviewing the teaching training course. A serious post-mortem discussion group? which is probably what this is right now in stitu
    • might just have to admit that you will scare some people away and live with it; or you will need to provide more scaffolding for those motivated people who don’t have all the pre-requisite skills; or refer people to a later round after they get skill x
    • Don’t assume you know skill level of TT students; assess. Have a questionnaire/survey (not a test, and not necessarily to weed people out) E.g. how often have you used Python (R, SQL, version control, unix shell, etc) in the last X weeks or X months or X years? What do you use it for? (context)
    • re. GitHub skills
    • Note: in the SWC Lessons collection, the lesson on version control says “git” and only covers “GitHub” in the last lesson.
    • I experience the GitHub skills issue as different form general knowledge; it’s more related to assignment submissions (since, as we’ve been told, groups prior to round-12 did not have to use GitHub to make submissions); it’s extra cognitive load for the course that needs serious scaffolding
    • we need to be more clear: version control, git, GitHub are different things; also Markdown is not Jekyll or other flavours of markdown; I suspect most of the confusion about md is really about Jekyll and how GitHub uses md (since *basic* md was designed to be simple)
    • One solution to the GitHub hurdle is to make the first session of Teaching Training an optional session on how to use GitHub, the anatomy of the GitHub interface, that necessary and prickly header required by Jekyll, etc.
    • pair up volunteer recent novice “grad” of TT with new novice TT student for duration of whole TT course as resource; find people of similar “novice” levels
• Matt Probert (U York)
  • 5 mins is short. Need to make sure font big enough
  • No different - just need good prep
  • 5 - still not very fluent
  • Some experience in teaching already
• Matt Dickenson
  • Much more prep-time than face time goes into teaching
  • Teaching online requires more effort in terms of technical setup and making sure you’re being clear on terminology and tone
  • 10
  • Basics of Git/Github (clone, pull, commit, push, merge), basic shell commands (ls, cat, grep), and at least one scripting language (Python or R)
• Morgan Taschuk (OICR Toronto)
  • Scrolling is not good. Having good contrast on-screen is important. Talking slower is also good.
  • You can’t judge if people do or don’t understand something. I usually use visual cues a lot to judge if I’m going too fast or too slow, or if I need to spend more time on a particular topic. I didn’t have that online.
  • 8-9
  • I think one of the issues with the training is that it’s for *all* the lessons. Even if a person is good at R, it doesn’t mean that they know (or should know) how to use databases before taking this training course. Or git. That said,
    • I think that instructors should know/be able to teach at least one of the topics in instructor training before taking the training…
    • Ask people to submit a short video of themselves teaching one of the topics to see if they know what they’re talking about? Then you could even do a before/after to see how their teaching style changes through the course
• Brian Magill (SSAI, York County, VA)
  • I need a lot of practice of the course of a few days. Even though I have done a little teaching before, I got the jitters. Also need to work on recovering if I stumble.
  • In teaching online I missed have the visual and verbal feedback that comes with having an audience in the room. Getting the software to work was a little bit of a hassle. Minor overall, but it is easier only to have to speak to people and draw on a white board.
  • As far as posting materials for Software Carpentry Training, I feel moderately comfortable, maybe a 4 or a 5. (Just have to remember to have all of my browser’s capabilities turned on when I do a pull request. I am not as comfortable with using GitHub for collaborating on software projects. I have used Git itself for many years, but only to save things locally. My current project at work uses Subversion.
  • As for as what people should know before taking this training, you could recommend some prerequisites. Since we are not getting graded and this isn’t part of an official accreditation, you could leave it up to the individual to decide whether she or he is ready to take the training. I look upon the training as valuable knowledge in its own right.
• Martin Bentley (NMMU)
  • That actually picking a small topic is really helpful. It is very easy to over-reach and try to do to much. I figured a short overview of the differences between lists, tuples and dicts would be small enough, but I could have compressed it down even more to just deal with the comparison between lists and tuples (and probably just one of those would have been enough to try and do).
    • I seem to have done OK for my first time teaching online. It felt fairly natural, apart from the lack of feedback. Just how valuable that feedback is. Ideally I would have another screen with the other people visible, so that I can see if they look confused somewhere.
  • Much less feedback is visible. You need to actively prompt to get any.
    • I was able to get things across, but I would not have been able to if I used my usual handwaving and gesture-filled stuff that I do for geology. So I did work slightly differently.
    • Much less control over things: I could not actually do a screencast, so had to improvise.
  • I still feel fairly comfortable, although I have learned some useful things, this is partly because I have been using it more for other stuff as well. So probably 7 for most things. I have not needed to do anything weird about rebasing and squashing commits and such.
  • Regarding requirements:
    • Maybe get people to do some initial tasks around git/github/jekyll before it starts, since that seems to be the source of much of the grief that people are experiencing.
    • Perhaps this can be linked into having people who have just completed this course giving some lessons to get the next intake up to speed. Something akin to: “If you are unclear on the basics of git/github/markdown, please attend one or two of these sessions, the learning curve is rather steep, but not impossible. The last group found it more challenging than we anticipated, so we are trying to provide additional support from the get go.” I know that I would be willing to do some lessons for people.
      • That said, I suspect that a good introductory guide, specifically for the sw-training repo could be very useful as well. Essentially to cover what needs to be done to have a working git repo locally, what and how the YAML in the frontmatter actually does (and why it is needed), how to push to our fork on github, how to create a PR (on github), and how to pull from the main SWC repo. That seems to be the workflow that is tripping people up.
    • I think in general that people should probably have either attended a bootcamp or have some exposure to command line interfaces and the basic tools we use (Python or R, git, &c). The exact programming language is probably not too critical, I think if you know your way around one then you can grasp the basics of another.
    • Possibly a broader overview of what will be covered. I was not expecting to be learning about teaching methods and theory of learning and such (it has been really interesting though!), which might be because I am doing this online only without having had a chance to attend a workshop myself (the only one that I know of that has been reasonably close (read: in the same country) was poorly timed in terms of other commitments that I could not get out of for me to attend).
• Marios Isaakidis (Mozilla Reps)
  • People get interested or bored in the very few first minutes you present a concept. Fail to stimulate their curiosity and you have lost them.
    • Examples are probably the best way we learn, especially if we have “intentionally” been mislead by the instructor.
  • Live feedback from the students was missing and was difficult to know whether one of them is left behind
  • 8
  • Go through the git swc material, maybe read about jekyll and markdown as well
    • Who was their favorite professor in highschool and later in university, and why.
• Heather Gibling (free spirit/unemployed)
  • 5 minutes goes by fast! I speak quickly when I’m nervous (though I already knew this) and need to focus on slowing down.
    • I wasn’t as nervous as I anticipated I would be.
    • I also developed a new level of appreciation for my R professor who taught with live coding that I didn’t have while in their class–it’s easy to make mistakes and go too fast.
  • The only real ‘teaching’ I’ve done in person was as a tutorial leader in undergrad, and in showing science demonstrations to kids. But it makes it tricky when you cannot see the faces of your students while screensharing as you don’t know if they look lost or bored.
    • Also, hand gestures are useless when screensharing.
  • Maybe a 7? I’m still concerned about what to do when a merge conflict arises.
  • I made a comment on the github issue about this: https://github.com/swcarpentry/training-course/issues/445#issuecomment-89056716
• Elizabeth Wickes
  • I thought that having a powerpoint slide of key terms would be helpful, but they each thought it was distracting.
  • I’m used to doing demos and looking for students faces for feedback.
  • Eh… I feel like I’ve correctly memorized the steps for committing a blog post page. But not much more than that.
  • Intermediate skill in at least one programming language. Maybe experience in at least one versioning system, but that can be argued.
• Victor Kwangchun Lee
  • Live coding can be an effective tool for delivering verbs not nouns to novices
  • Through Google hangout, can reach many more people, but while live coding, I could not get feedback.
  • 8
  • If attendees who participated in SWC workshop before, pre-assessment questionnaire can be a good starting point, but unless, we make homogeneous groups as possible.
• Darya Vanichkina
  • Needed to be better prepared for the unexpected and learn to figure out how to move on in the lesson if things didn’t have as planned (I was trying to get the error in the python floating numbers vs integers and it wasn’t happening). And I fumbled between moving on, and skipping over the material and then reintroducing the integer vs floating division in another section
  • Can’t use visual cues for assessing learning.
  • 7
  • For them to have to have gone through all of the SWC material before signing up, better if in a workshop, but OK if just independenty. And to ask honestly, no need to quiz or assess this in any formal manner.
• Kristopher Keipert
  • I wasn’t prepared to stray much from the lesson plans.
  • Lack of nonverbal feedback.
  • 8
  • Comfortable enough to use at least 1 of the major SWC curriculum themes in his/her own work

Notes

• Online teaching removes many of the usual cues that one gets talking to a room.
• A useful trick is to have people in the room as well as online. So one can get the subliminal signals.
• initial diff. in attention amplified by keener exchanges
• teacher expectations; student more forgiving w. live coding than you think
• relation btw confidence and how much you stick to script; more confidence // more improvisation
• why useprose in our lessons online, not bullet points? – prose shows flow of argument, link; more clear when reviewing afterwards
  • It also prevents the feeling that instructors need to use these lessons as slides.
• Methods for engaging your audience:
  • Using sticky notes to ensure you’re interacting the room. Give every student a small number of stickies. every time that student answers a question or speaks, they take down their note. Notes don’t go back up until everyone has spoken.
  • Or, a python script that prompts you at intervals to ask a randomly-selected student a question.
  • Scan the room, making eye contact with people in different areas of the room
• Book recommendation: “Teach Like a Champion” by Doug Lemov http://www.amazon.com/Teach-Like-Champion-2-0-Techniques/dp/1118901851
  • reviews thousands of hours of teaching videos to look for commonalities in teachers whose students do consistently do better than similar ones.
• Don’t teach from simplicity to complexity–start with a topic that shows students why this lesson will be useful to them (a ‘wow’ factor)
• Re-engage students by asking for an explanation from one student, then ask another to re-explain *that* explanantion
• Think-pair-share – students think individually, then discuss individual thoughts in pairs, then share with group.
• Pair programming – code in pairs. Each group has one copilot and one pilot. the pilot remembers and directs how the code is written, and the copilot actually writes it.
  • Extra helpful if the pilot is more experienced ; causes knowledge transfer.
  • should only be used on the ENTIRE class, never on “struggling” students only
• Etherpad is also really helpful for encouraging shy/quiet students to ask questions and participate. (also perhaps allows talkative students to express themselves without dominating the discussion?)
• Hard part of teaching online: less feedback
  • including feedback between students - amplifies impostor syndrome
• How strongly should you stick to the prepared lessons?
  • Depend how confident you are with the material
• Long form explanation
  • easier to recapitulate than point form notes
• Live coding is important - ideally keep the history including the error and keep the footprint how to get to the different points
  • Tab-completion is in principle good and e.g. help to write longer, more expressive variable names but might also be confusing; no clear solution here
• How can we get feedback in the online teaching:
  • get two people into the room and broadcast to the rest
• Companies to which you can upload videos and get feedback; this helps to share the how / the way
  • http://www.edthena.com/
  • https://www.beasmartercookie.com/
• Screen-cast
  • Windows
    • Built-in
  • Mac
    • QuickTime (should already be installed)
  • Linux
    • SimpleScreenRecorder
    • ffcast
• Lateral knowledge transfer: the things you transfer when teaching (like keyboard shortcuts) that you weren’t consciously trying to teach