Coaching Rules, Tips and Tricks
As much as possible, we want our coaches to follow some guidelines.
During the workshop you'll work in a small group of 3 learners. This is a hands-on, experience-oriented workshop. You'll stand by on the sidelines, not in front of them.
Coaches need to be 100% focused on their learners and always be there when needed. Make sure their experience is positive and that they have fun. Do not judge, be helpful and appreciate their (in-)abilities.
For attendees who are hard of hearing or would otherwise benefit from forms of communication other than talking, be prepared to use a text-based form of communication. Give them your Google hangout or Skype name and encourage them to IM you when they need help. (And remember to bring a laptop so you can check your IMs!)
Attendees with low vision might want to increase the size of the text in their command lines, their text editors, and on web pages. They probably know how to enlarge text in their web browsers, but they might need help resizing text in other places. Don't assume anything about someone's vision; try to start the day with the statement, "And if you need help making the text size bigger or smaller when you start coding, let me know!"
Sometimes attendees can get overwhelmed. This is why breaks are built into the schedule! If you feel like an attendee is getting frustrated and would benefit from a break, let them know that it's okay to step away for a few minutes, take a sip of water, and come back. Sometimes just moving your body can help new concepts crystallize.
At all times, you need to be super careful about the words you use.
It's hard, but possible. Don't use words and technical terminology that kids wouldn't understand.
For your learners it may be the hardest thing they've ever done. Telling them that "it's easy" is not cool. Saying "just…" suggests that it's simple and they're failing if they find it hard to understand.
Don't act surprised when people say they don't know something. Not knowing something (technical or not) is totally acceptable at Django Girls.
Be prepared even for questions like: "What is a directory?" or "How do I create a file?".
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation.
Subtle-isms are small things that make others feel uncomfortable, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle-ism. Like the other three social rules, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on.
The above two sections come from Hacker School User's Manual which is a highly recommended resource for teaching.
As we already mentioned, we want our attendees to really understand what they're doing, so they're not only copy-pasting the code, but they're actually learning something. That's why we chose the "learn from mistakes" approach here.
Over the course of the tutorial you'll see that we're trying to first steer attendees into an error, bug or mistake. Make the attendee read the bug report and understand it. More importantly, we're trying to teach them that bugs aren't scary and that error pages are their friends. This approach will go a long way later on.
The ultimate goal of the workshop is not to build a website. It is not to teach the whole of Django. It is also not to teach programming.
The ultimate goal is to show that code is fun. To get people excited. To show them that programming is not scary and that it is for everyone. To show them how powerful programming skills can be.
This excitement and passion will then drive them to spend endless hours trying to figure all of this out during and after the workshop.
Excitement is good, but stress is bad for learning. We really care about the atmosphere and giving our attendees a great first experience with coding.
Imagine this: You're trying to do something difficult. You're in a room full of strangers who know how to do it better than you. You don't know how to articulate your questions. You don't know the right names for everything.
For most people, this is a very uncomfortable and stressful situation. But it doesn't have to be! You're there to make it easier. Here is what you can do:
Smile!
Make eye contact
Admit that you don't know everything
Tell them it's ok to make lots of mistakes
Tell them it's ok to get frustrated
Use normal language, not jargon!
Assume everyone you're coaching has zero knowledge but infinite intelligence
Go at their pace, not your pace.
Be friendly and kind
Use their name
Make sure they know they're awesome!
Ask them if they need help -- some people are afraid to ask
Emphasize that there is no such thing as a "dumb" question
Don't say "Any questions?" Say "What questions do you have?"
Talk sssssslllllloooooowwwwwwllllllyyyyyyyy
Wait much longer than you feel is comfortable for questions/comments
A big obstacle that we try to remove is fear. In most situations, but especially school and work, people are afraid of looking stupid. This fear frequently keeps us from asking important questions like "how does that work?" or even just "why?".
Fear of making mistakes also keeps people from making progress.
Your group is using Windows but you're more a Mac or Linux user? Don't worry, you will do fine! Python installation got easier on Windows and there are other coaches to help you in case of a problem.
Madeline Kunin's research: women self-filter more than men.
The impostor syndrome is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, they remain convinced that they are frauds and do not deserve the success they have achieved. Impostor syndrome is particularly common among women.
To fight impostor syndrome:
Don't accept any learner saying they are too 'whatever' to do it; assure them that they can do it.
Congratulate people on their achievements and take some time to let them show you what they've done.
Compliment their work.
Show them that they actually know things.
We do not roll our eyes or laugh at questions. We do not debate which programming language, methods or technologies are "better".
We always answer positively:
I’m glad you said that
Great question
Hm, I'm not sure... Let's look on the internet/ask someone else.
Imagine that their keyboard is made of lava. LAVA! You wouldn't touch it, right?
Whenever you take over their keyboard, learners are going to drift away. This can be offputting and even scary.
We're sure you can explain what needs to be done and instruct them with your words only (it's actually a cool exercise for you too!). If you absolutely, ultimately must type something on their computer — chances are you don't — ask whether that is okay with them and explain what are you doing.
Ask: "Do you mind if I type?" or "May I?".
Attendees will only spend 8 hours or so with you, but they will have to spend many many many more hours teaching themselves. Fortunately, you can make it easier for them!
Make them Google stuff - do not give immediate answers just to make things go faster. It doesn't matter if you are going faster or slower -- what matters is whether they're going to fall in love with it or not.
Ask about their ideas - "How would you solve it?", "What do you think?". Make them figure it out on their own. You know they know it, right?
Encourage them to make their own changes and not to follow the tutorial too precisely - if they try to add some twists, and don't follow the tutorial at every step, they will learn much, much more. It is easy to copy-paste some code and put it in the correct location. It is harder to add something on your own and make it work.
Depending on the organizer's decision and the number of volunteers, some workshops can have meta coaches, who are not assigned to any group. In addition to them being more available since they don't have their own group, often they have more experience with debugging technical problems, so feel free to ask them for help if an attendee gets stuck.
Note that as the name "meta coach" implies, your primary role is to be a coach for coaches. This means all of the coaching rules, tips & tricks in this manual apply: meta coaches are available to help, not to take over. You should always acknowledge and communicate with the coach before helping a member of their group, ideally working through the problem together. This approach ensures coaches remain empowered and that in addition to learners getting the help they need, coaches become better coaches. A perfect recipe for a meta coach!
Introduce yourself to the coaches one-by-one at the pre-event (if there is one), or at the very beginning of the workshop (as everyone is still arriving), to make sure they know they can turn to you with questions. This is also a good time to ask whether there were any technical issues with the installation. Some problems that appear minor during the installation can cause major issues later on, which might mean having to repeat a large part of the tutorial to fix them, potentially re-installing python, virtualenv, django, etc. (other minor problems stay minor, so in many cases small deviations from the tutorial's installation steps are fine).
As a meta coach, expect to have some idle time during the workshop, i.e. you might get bored at certain points — this is a good thing since it means that everything is working ok and also that you are available to answer questions as they come up instead of participants or coaches having to interrupt you as you are helping someone. Our experience is that most questions and issues come up during installation (before or at the very beginning of the workshop) and at the deployment chapter, but in between these expect to have slower periods.
Many questions you will get are going to be technical issues: bugs, version incompatibilities, etc. Sometimes these are good opportunities to explain some technical detail, but often they are going to be some pesky detail that just stands in the way of proceeding with the rest of the tutorial. You will have to judge the participants' stance to the question to be able to provide the most effective support: do they want to learn how to figure out the problem themselves, or do they just want to wave a magic wand and move on? Although the aim of the workshop is not to finish the tutorial, and dealing with technical problems can be a good learning experience, sometimes the "wave a magic wand" alternative can be the right choice since dealing with technical issues can become very frustrating. However, make sure that it is the participant and not you who makes this choice.
This also means that often a quick workaround might be a better idea than some idealised 'proper' fix, which might take too much time. Use your best judgment to decide whether some quick fix will solve the problem (including whether it will cause any issues with later steps in the tutorial) and whether to try a more complete one.
Note that since the participants are using their own laptop, their systems settings and installed software might cause issues with following the tutorial. Also note that the software installed and configuration changes made during the tutorial might also affect other tasks they use the laptop for after the workshop. As much as possible, avoid changes that might break some other software installed on the laptop and be very careful with changing system settings. Having a participant feel that the workshop "broke their laptop" would be quite catastrophic!
Often you will be asked only for confirmation — "will this other version work / will this break something" — depending on the technical aspects, this might be a good point to warn (for example when using python 2.x instead of 3.x) or just reassure (for example python 3.4.8 instead of python 3.4.7). When handling questions like this, make sure to acknowledge that the issue raised is valid, and if possible explain why you consider the risk of breakage to be high or low.
If many participants have the same issue, pro-actively warn other coaches and groups about it. For example occasionally a version change affects some behaviour the tutorial assumes which means an issue might not be isolated to a single participant's laptop.