Advice for Teacher and TAs

This is taken directly from the slides for the RailsBridge teacher training, so it lacks the rich discussion that happens at an actual training. It's pretty long, but will give you a lot of stuff to think about, so forge on!

RailsBridge Fun Facts

  • Founded in 2009 as a variety of initiatives, including Rails Mentors, Rails Bug Smashes, and the Open Workshop Project.
  • The workshops project was led by Sarah Allen and Sarah Mei.
  • Its goal: make the Rails community more diverse and more welcoming to newcomers.
  • Workshops are happening all over the world!

How does a workshop work?

There are a few different RailsBridge curricula:

  • Intro to Rails (a.k.a. "Suggestotron")
  • Intermediate Rails
  • Intro to Ruby
  • Front End (HTML, CSS, and a tiny bit of JavaScript).

First, we get all the necessary technologies onto the students' computers (the installfest). The next day we break into small groups and work through the curriculum.

Typical RailsBridge Schedule

  • Friday, 6-10pm-ish: Installfest — installing things over pizza & beer (usually no formal presentations)

    N.B.: the Front End workshop doesn't have an installfest.

  • Saturday's schedule, often:

    • 9-9:30am: Check-in, coffee, bagels
    • 9:30-10am: Opening presentation
    • 10am-12:30pm: Class!
    • 12:30-1:30pm: Lunch
    • 1:30pm-4:30pm: Class! (with a break sometime mid-afternoon)
    • 4:30-5:00pm: Closing presentation & retros
    • 5:00pm-late: After-party

Helping your students feel socially comfortable

Introductions

  • Do not skip this! Intros are really important for setting the tone of the class.
  • Include name, profession, why are you here, and something silly.
  • Don't rush, even if you have a big class.
  • If someone joins the class late, ask them to introduce themselves.

Icebreakers

  • Name games! Admit up front that most people are bad at learning new names.
  • Get people talking. The more comfortable they are at talking, the more likely they'll speak up when they don't understand something, or to answer someone else's question.

Try to suppress your (understandable) culturally-influenced sexism

  • Don't hit on people. No sexual advances. None. Even at the after-party.
  • Don't make sexist jokes. Or racist, classist, or ableist jokes. Call people out if they do.
  • Don't make gender-based generalizations ("Women are better at X, because ...")
  • Don't make references to people's bodies or state your opinion of them.
  • Don't use slurs.
  • Don't treat women as delicate flowers; do treat them like normal people.

Teaching Technical Things

Explain that:

  • Even professional developers are constantly learning new technologies, so being confused is normal.
  • Initial code is often terrible: don't feel bad, just refactor!
  • Mistakes == Learning!

Dealing with technical concepts:

  • Define technical terms! Several times!
  • Assume anyone you're teaching has zero knowledge but infinite intelligence.
  • Remember people's professional and code backgrounds (QA, DBA, C++, Java, JS) and relate where possible. If they are a cook, try a cooking analogy.

Encourage collaboration and interaction

  • Explicitly encourage students to try to answer each other's questions.
  • If a question is asked, ask if anyone in the class thinks they can explain.
  • Be especially encouraging of the first few questions, to try to get things rolling.
  • Good responses to questions: "I'm glad you asked!" or "I actually wondered that, too." or "Great question!"

Be Super Positive, Always and Forever

  • Students have diverse backgrounds. Appreciate this fact.
  • If they aren't getting a concept, avoid anything that might shame them.
  • Lots of people are already internally berating themselves for not understanding, so it's super important not to pile on to that in any way.
  • Don't be surprised when someone hasn't heard of something before.
  • Don't grab anyone's keyboard. Avoid taking over unless you think it's really necessary. Ask before you do. "Mind if I drive for a sec?"

Walk the Middle Path

  • Don't go too deep for your class level, but also, don't gloss over things.
  • When trying to be accurate, it's easy to go down a rabbit hole of specificity. Avoid.
  • Work with the TAs to make sure no one goes down that rabbit hole. Accountability!

Know what's going on

Cover logistics at the beginning of class

  • Planned breaks, lunch time
  • Remind students that there is a closing presentation at the end
  • Make sure they know where the bathroom is
  • Encourage them to attend the after-party

Establish a few ground rules

  • Questions are always welcome, even if the student thinks it might be dumb.
  • Explain that if someone has trouble (e.g., not getting the expected output), the TAs will help troubleshoot.
  • If anyone wants to switch classes, tell them they should feel TOTALLY COMFORTABLE switching at any point.

Don't be afraid to:

  • Call on people! By name!
  • Correct people if they're wrong. Be polite and encouraging. For instance:
    • "Well, this might work better and this is why."
    • "Can you explain how you came to that conclusion?"
    • "Does anyone have a different answer?"
  • Ask yourself questions and answer them.

Pace yourself!

  • Don't go too fast. You will probably go too fast. Check in occasionally to ensure everyone is still with you.
  • You can say the same thing THREE TIMES and it will not be boring yet.
  • When you ask a question, wait TEN WHOLE SECONDS before saying anything else. People need time to think.
  • Don't let the most advanced students dictate the pacing or answer all the questions.

What's a TA good for? Absolutely everything!

  • At RailsBridge, a TA is a volunteer who isn't leading the class.
  • If you're volunteering at your first RailsBridge workshop, you should probably be a TA.
  • Sometimes they are the technical experts (rather than the teacher), sometimes not.
  • Co-teaching is also an option if you feel like you can tag-team. There doesn't have to be a hierarchy.

Things TAs can do:

  • TAs often explain specific concepts for the class or teach a couple of sections to give the teacher a break from talking.
  • TAs can ask questions to encourage students to speak up.
  • Ask your TA to explain a concept; they may be more technically advanced than you!
  • TAs can help people who get lost.
  • If someone falls behind, the TA can take them out of the room to do some 1-on-1, if there's another TA in the room.

Student Comprehension

  • Pay attention to body language.
  • People ask questions most often when they are actively processing material. If they aren't, it might be that the material is too easy or hard. Try to figure out which it is!

Calling on people

  • Calling on people makes the class more interactive and engaging, and less lecture-y.
  • Don't always ask questions to the whole class: call on individuals by name.
  • Consider breaking the class into two teams and addressing questions to teams.
  • Ask people what they expect a command to produce BEFORE you hit enter.
  • Ask "How would you do #{this}?" or "If I wanted to do #{that}, what would I do?"

Installfest!

Keep in mind:

  • There will be people with all kinds of computers.
  • Even though Windows is not an ideal Rails development environment, we're here to encourage people and meet them wherever they are right now.
  • Do NOT say bad things about Windows, even if it's frustrating.
  • If you're not sure about something, grab another volunteer.

Very Important, Very Practical Things

We need your help! Thank you!!!

Making Tech Better Since 2009

RailsBridge is working to make tech more diverse and welcoming by teaching programming, connecting human beings, and listening to people's needs. We organize and teach free workshops on Rails, Ruby, and HTML & CSS in cities all over the world, targeted at groups of people that are underrepresented in tech. You can read our code of conduct here.

Want to suggest an update to this site? We use GitHub to keep track of our code. You can either make a pull request or create an issue.

Donate to RailsBridge

hello@railsbridge.org