In our penultimate online meeting this week, we discussed the demotivational stories people have been posting, walked through the final assignment, and talked a bit about how to run workshops and ways to get involved with Software Carpentry. The notes are below; long story short, the last exercise is:
- Pick one of our novice lessons.
- Submit a small change as a pull request on GitHub. (If you’re not comfortable with Git or GitHub, mail me and I’ll find you a mentor.)
- Teach a 5-minute lesson that includes that small change or create a 5-minute screencast on the same material.
- Create a one-page website for a workshop. (As with #2 above, the real goal is to make sure you understand the mechanics of doing this, and as above, if you want help with Git, GitHub, page editing, or anything else, we’ll pair you with a mentor.)
This is the first time we’ve given people a choice between a live lesson or a screencast. If you’re doing the latter, you should download the demo version of Camtasia on Mac or Windows; if you’re on Linux, the best choice seem to be recordmydesktop or kazam to capture data and then a video editor to cut out the ums and errs. (If you find something better, please post a comment here and mail the list — screencasting tools for Linux still seem pretty bumpy.)
I’ll send details by email on how to create a workshop webpage — we’re in the midst of streamlining things, and I hope that by the middle of next week, you’ll be able to try out the newer and simpler process. Until then, please concentrate on prepping a lesson. Please also keep an eye out for mail about your partner: as I said in the meeting, I’m going to pair you up so you have someone to practice your lesson with, and I’ll try to get that done over the weekend.
- Two themes keeps coming up: one is unfairness and the other is indifference.
- What demotivated people was that either people were treated differently from others or they felt that the instructor didn’t care
- The unfairness in our context, is people feeling that they’re starting from behind. They feel disadvantaged because they lack skills and knowledge others have and that they can’t catch up. People who use Windows tend to have more installation problems. Depending on the workshop any of 0-3/4 of our learners use Windows. If they’re being asked to install something not native to their platform, they feel it’s unfair.
- Instructors tend to use Mac OSX or Linux or even Chrome OS so we can’t troubleshoot our students easily
- There are many other places where that sense of unfairness comes up. It’s common to have people who have played with the command line before and others who have not that. The latter feel like that they’re starting behind, especially if the instructor is so used to the Shell that they forgot how weird it is.
- The sense of indifference is less a problem in SC. Where that seems to come up in our classrooms is that people who are less skilled put up their hand less often. If a learner doesn’t feel like they’re not getting the help they want, it becomes a downward spiral. If you’re not an instructor who’s lecturing, be proactive about seeking out who’s struggling. Stay at the back of the room and see how people are doing. Show that you care and go to learners and ask them how they’re doing. We don’t want to delay a class of 40 on the requirements of 1 learner, but the 40 will see how the 1 is treated and it decreases overall morale. One solution, is to take people that the lesson is completely not geared towards (the advanced) and ask them to help out those who are really struggling. They will learn from offering help and it will make them feel like you’re paying attention.
- What do you do if 1-2 people fall behind? Try assigning them a helper (if you have enough) and if possible get them into a side room so they don’t have to listen to themselves get further and further behind
- But at a certain point you have to accept the unavoidable loss
- What is the optimal student-teacher ratio? Well, 1:1
- If you have some very strong students, you can pair them with weaker ones — but do pair programming for the entire room instead of singling people out
- Other themes people found in the motivational posts:
- The power relationship in a classroom is very uneven. You are either the teacher or the student. One of the reasons we live code is that the more they see us screw up, the more the barrier goes down. That’s why SWC gets instructors who are fairly equal to the students.
- The purest form of politeness is showing people that you respect their time.
- “Aggressiveness as a teaching method” — not a good teaching style. Make sure that the other instructors can give you a hand signal to tone it down. Instructors get tired and aggressiveness sometimes come out of that.
- Public humiliation as a teaching method…
- “You’re not trying hard enough” — the great demotivator is blaming the victim.
- And we tend to blame ourselves
- Unclear expectations or seemingly ad hoc teaching methods (no forethought)
- One of the reason that MOOCs are not doing well is that there’s only one video. “Here’s the lesson” and if you don’t get, there’s no Plan A or Plan B. Tons of research shows that if you don’t get it the first time, it’s unlikely you’ll get it the second time. Most teachers change metaphors or adapt. In a huge room, you can’t adapt to every learner so large classrooms aren’t effective but teachers who stick to a script and don’t follow their learners are also ineffective. A set of slides is constraining.
- People come away from the SC workshop saying they were encouraged and disheartened. They were encouraged that they weren’t alone and for some of our learners that’s the biggest realization. The disheartening, yeah, there’s a lot of work to do.
- How do you get people to talk about the problems they’ve having to your/the instructor’s face?
- Ask them more generally, so that they can use examples from the past, hypothetical “a friend of mine…”
- Ask for one good one bad, with the limitation they can’t repeat a previous person’s statement so the first people say nice-bad things (“the coffee was late”) and everybody after that can say what they’re really thinking
- One wrap up exercise is based on a book Greg read: I used to think. But now I think (http://hepg.org/hep-home/books/i-used-to-think-and-now-i-think ).
- In it a bunch of educators wrote essays about things that they changed their mind about.
- One of the things we’ll be asked to at the wrap up is a short blog post about what we’ve changed our mind about. Not just about what we’ve learned but what we don’t believe anymore that we’ve used to believe.
- Try doing the motivation exercise with your lab mates if you’re in grad school.
Assignments for next meeting (Fri Dec 5 recommended deadline) Part I: Submit improvement to core lessons
- take a look at our existing core lessons. Pick a chunk and submit a small fix or addition. Add a multiple-choice question or change an example. We’re not looking for rewrites of entire sections, we just want to ensure that you’re familiar with how to review and edit core lessons. Little changes add up quickly.
- If you aren’t familiar enough with Git and Github to do this, don’t worry, we have lots of existing instructors who would be happy to mentor you. Email Greg and he’ll set that up. You’ll make the change on your own but comment on the changes at least 2 others made so that you’re familiar with reviewing changes. This is similar to scientific peer review but with a faster turnaround.
- “small fix” = change/add a multiple choice question, clarify wording of existing portion of lesson, add/change a lesson to meet an objective that is not yet well-met, etc.
Part II: Set up a home page for a workshop.
- Each workshop has a 1 page website set up in Github. The process isn’t very complicated. Again, you can be matched up with existing instructors.
- There is an existing video and documentation that explains How To but Greg is going to assign people to a mentor, so that we can assess if the process currently established is accessible/Troubleshoot it.
- There are always last minute changes to workshops and we want to be sure everyone’s comfortable with making them.
Part III: Teach a 5-minute lesson online.
- The lesson will include the fixes you made. You’ll be paired with practice partner before the lesson is put online. You’ll be giving each other feedback. Stay tuned for a checklist on giving instructors feedback. If the feedback is structured then both parties have an idea on what’s expected from them and how to do it.
- For screencasts:
- We are not asking you to make a screencast. Previously, that has been asked. A lot of people found that an interesting exercise but mostly what they learned was that it takes 3 hours to make a useable video. But it takes a long time to do that exercise and a lot of people dropped out. You can do a live video or a screencast. You will get feedback for both. Note: the screencast will take longer but you will learn more from it. Again, Greg will show you some tools.
- If you’re planning on doing a screencast, read this first: http://teaching.software-carpentry.org/wp-content/uploads/2012/08/chen-pattern-language-screencasting-2009.pdf
- If you’re on Mac and Windows, get yourself a trial version of Camtasia. It’s the MS Word of Screencasting. Greg used it to edit this: http://third-bit.com/2014/10/27/shuttleworlith.html . This video is also fun if you’re interested in the future of SC.
- You can also look at the tag: Screencast on teaching.software-carpentry.org . Greg would like to wrap by the end of November. This means we’ll spill over into the first week of Dec. If we don’t finish by then, this course will probably go into the New Year because of December’s Final Exam season. The biggest drop off occurs during this last exercise because it can stretch so far.
- Live:
- Screenshare or stand in front of a whiteboard
- Whiteboard: (Hard to do audio without clip-on mike)
- Screenshare: Google Hangout like previous practice teaching
- Most people screen share during lessons so that you can live-code. Occasionally, people do lessons in front of a whiteboard but the audio pickup is more difficult for that.
Getting involved with SW Carpentry workshops:
- Mailing lists: http://software-carpentry.org/pages/join.html broadcast of upcoming workshops that need teachers. ‘instructors’ list.
- There’s a ‘discuss’ list that has strategic discussions on the core curriculum, discussions about Git installation, etc. The signal to noise ratio is pretty good.
- Even if you’re inexperienced, go ahead and volunteer. You will be paired with an experienced instructor. Regarding location, we prefer people who are nearby but if you want to go to Germany and you see a workshop there, throw your hat into the ring. If we have people who are cheaper/can’t afford to fly you there we may say no but a lead instructor might prefer an ecologist helper far away than an astronomer close by. It’s a good way to visit other universities. In order for SC to sustain itself, it has to be good for the instructors.
- A cold call to send if you want to pitch to someone who has never heard of us: http://software-carpentry.org/blog/2013/11/updated-cold-call.html
- Who can run a SC workshop? http://software-carpentry.org/faq.html
- The name and logo SC can only be used if you have a certified instructor and are covering core topics. The material can be used in general as long as you credit it to SC.
- Minimum budget? Travel and accommodation for instructors. We strongly encourage a donation of 1,500$ + plane and hotel to bring someone in. Can be 1,500-3,000. Learners usually pay 20$/head in order to encourage attends. Funding arrangements are currently being discussed. SC is a non-profit and that makes things complicated.
- Usually organized by an individual prof, who pull the money out of grants, extra salary, prof dev funds, whatever
- Data Carpentry: http://datacarpentry.org/ — A sibling organization to SC. The idea here is that SC’s original mission was to teach scientist who were programming badly how to program better. Most scientists only care about data analysis. Datacarpentry doesn’t cover version control but they do talk about getting out of spreadsheets and into R and data visualization. Less of a focus on programming. The hope is that having two organizations with two names makes it clearer which workshop they should be attending. We are sharing instructors.
- We’re thinking of setting up another sister organization for libraries.
- The pre-assessment questionnaire: SC has no reliable way of separating learners (e.g. beginners — intermediate — advanced or “Preschool — Kindergarten — Grade 1″). There’s a pre-assessment questionaire that we’re revising. If you’re interested in contributing, email Greg. Sometimes we have the resources to have 3 rooms at different levels and use that questionaire. There’s no official discrimination between levels other than that. The distinction between novice and intermediate isn’t that black and white. Often times it’s the same material which just moves a little faster. Does it mean advanced topics or the same lesson moved faster because they have some prereqs? When you advertise a workshop, it’s important that you tell people what they should know beforehand but oftentimes it makes no difference. People will come whether they have prereqs or not because it’s the only access they have to software training. Be prepared for that.
- SC is trying to get involved in initiatives aimed at populations that are underrepresented in computing, e.g. women in computing workshops. Suggestions welcome.