Instructor introduction
This page gives general instructor and expert helper introduction material. These people are responsible for more than one breakout room, and have to have an overview of more of the course. In short, if you want to take the next step in CodeRefinery, this is the place to start.
See also
Co-instructors for an intro for starting co-instructors.
How do you get started?
That’s what this page is about (well, and the instructor training). We believe that you best learn by working with others in practice, and provide plenty of opportunities to do that.
Starting materials
Reading here: the other pages in the section, see sidebar.
Also read the team leader information
Team leaders - general on motivation and how to prepare for breakout rooms
Reading elsewhere:
As an instructor
Most of our workshops are very collaborative arrangements: you are rarely alone. This is one way of looking at it:
Look at and revise the workshops before they teach, making small, incremental improvements. But, you don’t have to (and in some sense, it’s good if they stabilize some more).
Especially go over the examples when preparing.
Have a chat with someone else (probably another instructor or expert helper) before teaching. We encourage this for everyone, even experienced instructors, to better transfer knowledge among each other and stay up to date with the latest developments.
Teach independently or co-teach. Ideally, co-teach the first time(s). Really, we’d like to get to the point where we always co-teach. Co-teaching doesn’t mean different people take different lessons, but two people teach all parts of the same lesson by turning it into a discussion between the two instructors. TODO: produce information on this.
in the main session
As an instructor, when preparing your lesson you first need to decide how to balance between the main room and breakout sessions.
Clearly say when a learner watches, when they type along, when they should work on something independently as an exercise.
CodeRefinery is traditionally a hands-on workshop, so breakout-room sessions should be a large part of the workshop.
We usually keep the main room mostly for general discussions. Small exercises or polls can also be done in the main room, for all hands-on exercises we divide the learners into breakout-rooms each with one team leader.
To give you an idea about how the work in the breakout rooms is going, monitor the hackmd closely and if time allows try to visit a few breakout rooms to see how it is going and if needed adjust the timing.
Preparing for the breakouts (in the main room)
As an instructor, you need to clearly define what the tasks of each breakout session is (even if it is just “explore and discuss”). Online courses need more “meta talk” about how you expect things to go, since it’s not as easy to read the room or fill in expectations later (distractions, hard to communicate to breakout rooms after opened).
Clearly say what the tasks of the breakout session will be.
Put that task and a link to the part of the lesson in the hackmd.
Clearly say how long each breakout session will be (make sure it’s long enough and adjust during the exercise session if needed)
Clearly say if things in the future will depend on this exercise (is someone completely lost if they don’t make it to the end. Halfway?)
Try to make breakout sessions longer:
imagine a 5 minute overhead for each session, getting people there, deciding who does what, acquainted with what they need to do, and debugging problems.
10 minutes is quite short, 20 minutes is best.
Can you say less and let people discover it for themselves?
As a team leader, if anything is unclear to you, it is very unclear to others. Comment/Ask in the HackMD or speak up and ask!
Top issues new instructors face
An example of a beautiful screenshare. Note the portrait orientation (you have half the screen free for notes and HackMD, learners have half the screen free to do their own work). The terminal is dark-on-light, a minimal prompt, no other fancy shell distractions, there is a shell history visible, and slightly distinct colors between the web browser and the terminal.
Breaks are not negotiable, minimum 10 minutes.
Breakout sessions too short. Make them as long as possible, don’t expect to come back for new intro, then go back.
People will accomplish less than you expect. Expect learners to be 5 times slower than you, at best!
All the other tools and stuff will go wrong. Try to not bring in a dependency when you don’t need it.
Trying to accomplish too much: it’s OK to cut out and adapt to the audience. Have a reserve session at the end you prepare, but are ready to skip.
Not clearly separating (in the learner’s mind, by meta-talk), the differences between demo, type-along, and exercise/exercise-prep.
Demo and type-along are hard to do at the same time: they are very different types of focus
Type-along and exercise of the same thing are not good to combine, leads to duplication
Explaining how, but not why.
Running out of time to making your environment match the learner’s.
Running out of time to set up good screen sharing practices (terminal history, portion of screen, remote history) in advance.
Assuming learners remember what they have already learned, or know the prerequisites. Or have stuff installed and configured.
Not managing expectations: learners think that you will accomplish everything, and feel sad when you don’t. Instead, say explicitly what everyone should follow along, what you might want to watch, what is only a demo.
Following the lesson as written at all costs.
For livestream courses:
Worrying too much (forgetting that there is a co-teacher and break time where you can discuss and plan your next step).
Speaking like learners should be able to speak up with voice, instead of “answer in HackMD or discuss within your groups.”
Forgetting to save time for Q&A: there is more Q&A because of HackMD. You might take a few minutes to screenshare HackMD and after each exercise session, after each break, after each episode, and at the end of each day.
“Stop screenshare” instead of letting the other person start and take it from you. Or, the broadcaster switching the scene. Never do “stop screenshare”.
Forgetting to screenshare the HackMD during Q&A time (this is the most important way learners know it is active, and thus feel a connection to the course).
Forgetting there are multiple ways to attend: not everyone is in a breakout room, not everyone has helpers nearby. Instead, use phrasing such as “for those of you in breakout rooms, go there now. Everyone, remember to ask any questions in the HackMD, even if you are alone.”
Planning to do a demo during team breakout sessions (teams will still hear your voice, if they mute the stream it’s hard to bring them back).
Sharing a fullscreen, not the 840x1080 portrait layout.
Showing non-creative-commons material on the stream.