Writing down the instructor training course

[gvwilson]

Work in progress: do not merge.

This PR will eventually be a written version of the instructor training course. Feedback is welcome at any time.

[DamienIrving]

@gvwilson It's really great that you are writing these up. I realise that the first lesson is a work in progress (i.e. you were probably planning on doing this anyway), but I think it (and all the subsequent lessons) is crying out for a summary section at the end. Since most of the trainees will be worried about teaching at a bootcamp for the first time in the future, I think this summary needs to be framed as the main learnings from the lesson as they apply to instructing at a bootcamp. In other words, the summaries are the thing they can flick back to weeks after completing the training course, as they are preparing to teach for the first (or second or third) time.

For instance, the summary of the first lesson (01-intro.md) might be:

• Learning consists of more than "just" conveying facts and techniques: it's just as important to create linkages between concepts.
  • Example: our introduction to the Unix shell seems light on facts (it only introduces 15 commands in two and a half hours), because the main goal is to help learners construct the mental model and notional machine that these commands fit into.
• People learn best when they care about the topic and believe they can master it, so we teach the things that are quick to master and immediately useful first
  • Example: the Python lessons start with reading data with numpy and plotting with matplotlib, not print hello world and a lecture on the fundamental data types associated with Python programming
• Programming is a skill that will improve with practice, not an intrinsic talent that you either have or don't have
  • We code live in front of our learners instead of using slides, so that they can see us make mistakes (i.e. we demonstrate that we aren't innately talented)
  • We get them to attend in groups
• And so on...

The other great thing about these summaries is that they give the instructor ammunition to defend the teaching materials. In my experience defense is required against attacks from within (e.g. a new instructor suddenly decides two-days out from the bootcamp that they don't like that we jump into numpy and matplotlib right away and starts wasting precious time re-factoring the lessons) and externally (e.g. a helper comes up to an instructor during a coffee break and suggests a change to the materials for the next session). In both cases, they need a clear and concise rationale for why the materials and bootcamp structure (e.g. live coding, sticky notes) are the way they are. The summaries should provide that.

[DamienIrving]

Comments from instructor training, session 1 (10 Sep 2014)

The teaching notes are missing the following topics that were covered during session 1:

• The 7 +/- 2 rule, short term memory etc
• Expert blind spot
• Details of the task that people were asked to complete at the end of the session

The following could be added to the teaching notes to aid new instructors:

• The main method for breaking up the content during the skype call is via polling the audience. You could scatter some polls throughout the teaching notes, a bit like challenges are scattered throughout the novice materials (e.g. the question about the difference between phonic and whole language approaches to teaching kids to read was a nice poll that could be added to the notes)
• You often get asked during the skype call for references to back up what you're saying. Those will definitely need to be in the notes, as new instructors won't be as familiar with educational literature

[DamienIrving]

Comments from the instructor training catch up session (for session 1) that I ran with a couple of people from New Zealand (20 Sep 2014)

I wasn't sure how to fork your fork, so I figured it would be easier just to add comments on 01_intro.md here:

• I think 01_intro.md needs to start by outlining the rationale for running an instructor training course, and why we have chosen to focus primarily on educational psychology and instructional design as opposed to programming and software skills. When explaining to the New Zealanders, I made the following points:
  • New instructors (usually) already have more than enough programming/software knowledge to teach novices
  • New instructors (usually) have very little knowledge about educational psychology and instructional design
  • It’s important to bring would-be instructors up to speed on educational psychology because (i.e. we put you through a 14-week course because):
  • If we just handed the teaching materials to instructors without explaining the rationale behind their design, we’d get very different results (e.g. in my experience some new instructors have tried to re-design the whole course the night before a bootcamp, others have cut out really important parts out because they didn't have an understanding of why those parts were in there in the first place)
  • We’d like new instructors to contribute to the development of the materials going forward. For that to be effective, everyone needs a solid understanding up the principles underpinning their development
  • We want to provide the best possible learning experience. Instructors who are knowledgeable and committed enough to get through a 14 week course will probably be better teachers (although we can't prove that)
• Prior to the paragraph that reads "What we know about educational psychology constrains teaching, but doesn't dictate it..." you could have a heading like, "There's more than one way to skin a cat"
• At the end of that "skin a cat" section you have an indented block titled "the song remains the same". A concrete example that would go nicely in that box is the fact that our very first lesson on Python jumps straight into a data analysis task where we read in data using numpy and create a plot using matplotlib. We are essentially going for the whole language approach here - it's not the only way to teach programming to scientists, but when you've only got two days there isn't time for a slower phonics-style approach.
• In the discussion of why "broadcast mode" teaching isn't effective, you might want to mention that this is why we have so many helpers at a bootcamp and so many challenges for the participants to complete in pairs. It's during those challenges that the participants get to have their misconceptions clarified by their colleagues and the helpers. I'd argue that this is where the real learning happens at a bootcamp - I've been to bootcamps where the live-coding/teaching has been terrible, but it's still been a wonderful learning experience for the students because of the discussions they have with helpers and colleagues during the challenges. It's also why we don't provide answers for the challenges (i.e. we don't "broadcast" answers) - we want them to have to talk to each other and the helpers.