As much as possible, we want our mentors to follow some guidelines.

Be hands-on! Mentoring vs. teaching

During the workshop you’ll work in a small group of learners. This is a hands-on, experience-oriented workshop. You’ll stand by on the sidelines, not in front of them.

Mentors 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.

Be flexible and accessible

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 Slack name and encourage them to DM you when they need help. (And remember to bring a laptop so you can check your DMs!)

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 crystallise.

Words

At all times, you need to be super careful about the words you use.

Use inclusive language

Use inclusive language and be careful to avoid using gendered language as much as possible, especially when addressing a group. Muses proactively welcomes non-binary and gender non-conforming folks to attend our workshops, so using “guys” and “girls” can feel exclusionary. We know it’s hard as often it’s said unconsciously - but words and intentions are important, and people will appreciate an imperfect self-correction over nothing. Trust us.

To be more inclusive, please use terms like “everyone”, “you folks” or “you all” and avoid making any assumptions about gender, identity, etc. At the start of the day, ask everyone to introduce themselves and their pronouns as part of an ice breaker, and add this to their name tag, Slack profile, etc.

No jargon

It’s hard, but possible. Don’t use words and technical terminology that kids wouldn’t understand.

Don’t say “it’s easy” or “just…”

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.

No feigning surprise

Don’t act surprised when people say they don’t know something. Not knowing something (technical or not) is totally acceptable at Muses Code JS.

Be prepared even for questions like: “What is a directory?” or “How do I create a file?”.

No well-actually’s

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.

No subtle-isms

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.

Learn from mistakes

As we already mentioned, we want our attendees to really understand what they’re doing, so they’re not just copy-pasting the code, but they’re actually learning something.

If they run into an error, 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.

Learn that coding is fun

The ultimate goal of the workshop is not to build a website. It is not to teach the whole of JavaScript. 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.

Atmosphere

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 mentoring 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

Removing the roadblocks

Fear

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.

I’m not used to working with Windows/Mac/Linux!

Your group is using Windows but you’re more a Mac or Linux user? Or vice versa? Don’t worry, you will do fine! Installation has gotten much easier and there are other mentors to help you in case of a problem.

Impostor syndrome

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.

Answering questions

We do not roll our eyes or laugh at questions. We do not debate which programming language, methods or technologies are “better”.

Don’t be discouraged if you’ll sometimes need to try a few different explanations. Most attendees will be beginners, so they won’t have many existing points of reference (bonus point: nor will they have any bad habits some programmers tend to pick up along the way). If you get to the end of the tutorial, you can explore additional guides at the end or work on whatever your group is most interested in. You can also prepare your own challenges for attendees or explore helpful resources (documentation etc).

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.”

If you need help with anything, don’t be afraid to use Google or ask another mentor to help you out. It’s great for them to see you fearlessly Googling and asking other developers questions - that’s a huge part of coding!

No back-seat driving

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?”.

Show them how they can teach themselves

Attendees will only spend 6-7 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.