Facilitating Labs

Lab time is when we get to directly interact in-person with students. During labs, we don't have a lot of time to consider our words or actions, so it's important to be prepared to help students in a friendly and open way. Often, we don't realize the impact our words and actions can have, or how they can be differently interpreted, especially when we are discussing concepts we are so familiar with.

Lab Obligations

Each instructor in WATS is required to attend one lab session per week, per course. If you are teaching one course, then you will attend one lab session per week. If you are teaching two courses, then you will attend two lab sessions per week.

You will work out your lab schedule with the Director of WATS prior to the start of the quarter, and that schedule should remain as consistent as possible to insure coverage in each lab session. If you need to miss your scheduled lab, communicate that to the Director of WATS in order to work out a replacement or alternative coverage.

During lab you will assist students on projects and coursework. You will work with all of the WATS students, not just those in your course. You should attempt to answer any questions you can, and don't be afraid to refer questions to other instructors if that is a better solution.

Some students will show up to just work on their coursework, as a way to discipline themselves in their studies. Others will come in with specific questions and leave as soon as you answer them. This is all fine.

Grading Labs

Students must attend one lab per course per month. That means if they are enrolled in two courses, they must come to lab twice each month of the quarter. (A total of six appearances in lab.)

When you come to lab you should bring a device or notebook to note who attends. Or, if you prefer, you may enter directly into Canvas. (But in general instructors don't need computers in lab, and you should be wary of using grading in Canvas around large groups of students. We must insure privacy for student grades.)

Lab Tips

The tips below are adapted from the Django Girls Coaching Manual. They echo policies and practice used at many different tech teaching schools, hackathons, and boot camps.

Words

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

No jargon

It's hard, but possible. Don't use words and technical terminology that students many not fully understand. Remember that it's your job to educate students in these terms and help them grow, so when you do use technical jargon, be consistent and ready to explain.

Don't say "it's easy" or "just..."

For your learners this 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.

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

Remember: You are here to educate, not to judge students' existing knowledge.

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.

The above two sections come from [Hacker School User's Manual](https://www.hackerschool.com/manual) which is a highly recommended resource for teaching.

Learn from mistakes

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.

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

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

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

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.
• No back-seat driving

Don't touch the keyboard

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!).

Show them how they can teach themselves

Students only get so many hours with us, but they will have to spend 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.