You're an expert. Here's how to teach like one.

Guidelines: Puns, jokes, or “hooks” in titles are okay, but make sure that if all someone knew was the title, they still would have some idea what the presentation is about.

Knowing how to code and being able to teach it are two separate skills. When we have expertise in a subject, it's common to take for granted that we'll be able to effectively communicate our expertise to someone else. Come learn (or re-learn!) how to teach and discover practical examples you can put to work right away.

By sharpening your teaching skills, you'll be a more effective mentor, trainer, and team member.

Guidelines: Both your title and this description are made public and displayed in the conference program to help attendees decide whether they are interested in this presentation. Limit this description to a few concise paragraphs.

No previous teaching experience is required, but this talk can benefit anyone who trains, mentors, or teaches others (formally or informally), especially:

• Someone who mentors a junior developer and wants to help them reach their potential
• Someone who manages mid-level developers
• Someone who communicates technical information to non-developers
• Someone who trains developers or teaches coding at any level

After the talk, you will have practical takeaways to help you more effectively communicate with developers and non-developers alike.

Guidelines: 1–2 paragraphs that should answer three questions: (1) Who is this talk for? (2) What background knowledge or experience do you expect the audience to have? (3) What do you expect the audience to learn or do after watching the talk?

Committee note: The “Audience” section helps the program committee get a sense of whether your talk is geared more at novices or experienced individuals in a given subject. (We need a balance of both lower-level and advanced talks to make a great PyCon!) It also helps us evaluate the relevance of your talk to the Python community.

1. Know your audience (8 minutes)

   • Connect with your audience. Why should they listen to you? What can you offer them?
   • What are their motivations? Knowing why your audience wants to learn can help you tailor your lesson.
   • Empathize with your audience. What is their level of understanding? Don't assume.
   • Don't make anyone feel "less than". Nobody likes being talked down to.
   • Remove distractions. What might get in the way of learning?
   • Remember your journey. You didn't become an expert overnight. Where are they in their journey? Remember that this was difficult for you once, too. Nobody hits a home run their first time.

2. Examples that connect (7 minutes)

   • One concept at a time. It's challenging to learn more than one thing at a time. Which is the thing that actually had the effect?
   • Use examples of things people already understand. At Hear Me Code class, we take attendance to teach for loops and again to teach enumerate()
   • Specific examples are better than abstract generalizations. Foo/bar/baz are less helpful than any specific example.
   • Model good behavior. If you're providing sample code, use meaningful variable names.
   • Be practical. How will they be able to use this? We demo real (skill-level appropriate) projects at the end of class.
   • Why? So what? When will I use this? These questions will help clarify if your examples are practical.
   • Be flexible. Great examples connect with most people, but it's rare that one size fits all.

3. Know what to hold back (3 minutes)

   • Answer the question that is asked. Offering lots of extra information or going on a tangent can often confuse new learners.
   • Teach the pool, not the ocean. Knowing what is relevant in the moment and what is best saved for later is key to not overwhelming new learners.
   • Nuance isn't always helpful. For new learners, teaching the most common situations is better than teaching a corner case they might never encounter.

4. Fostering a love of learning (7 minutes)

   • Celebrate progress. Positive feedback encourages growth. Negativity stifles learning.
   • "I don't know, let's find out." This magic phrase encourages questions and is a reminder that you don't need to know everything; learning never ends.
   • "Great question. I love your instincts." Don't be annoyed when the learner is mentally jumping ahead a few slides and asking about material you're about to cover -- that's a sign that you're doing a good job!
   • Move about. When possible, teaching concepts through movement makes for unforgettable experiences.
   • We learn by teaching. Teaching reinforces what we've learned, forces us to think flexibly, and creates bonds.

Guidelines: The “outline” is a skeleton of your talk that is as detailed as possible, including rough timings for different sections.

Committee note: The outline is extremely important for the program committee to understand what the content and structure of your talk will be. We hope that writing the outline is helpful to you as well, to organize and clarify your thoughts for your talk! The outline will not be shared with conference attendees.

I am the founder of Hear Me Code, an organization that offers free, beginner-friendly Python classes for 3000 women in Washington, DC. The principles outlined in this talk have been key to Hear Me Code's success not only in growing the community but also in fostering the learning and growth of women in the program. I have developed the curriculum with these concepts in mind, and continually iterate and refine the curriculum to improve the learning experience.

Hear Me Code members who have frequently served as teaching assistants and teachers have created a helpful list of practical tips for first-time (or long-time) teaching assistants: https://github.com/hearmecode/ta-tips

Guidelines: Anything else you would like to share with the committee: Speaker public speaking experience. Speaker subject matter experience. Have the speaker(s) given this presentation before elsewhere? Links to recordings, slides, blog posts, code, or other material. Specific needs or special requests — accessibility, audio (will you need to play pre-recorded sound?), or restrictions on when your talk can be scheduled.