Meaningful Mentoring Moments

- I run Python Morsels **(click)**, which is a weekly exercise service that helps developers deepen their Python skills in ways that day-to-day coding doesn't - I also run a training company, Truthful Technology **(click)**, which gives the me opportunity to help ye clients level-up their team's Python skills through hands-on training sessions - I'm going to be talking about some of the things I've learned while teaching Python to teams - I'll also be drawing on my experience organizing meetups and coaching at volunteer-run Python and Django workshops over the years - **Disclaimer**: I don't have a background in teaching teachers, *but* I have learned a few things over the years about teaching, coaching, and mentoring that I feel qualified enough to share...

Show of hands

What we're talking about

You're helping someone with their code coding abilities
This helping relationship might be temporary
~~Python~~
Teaching and pedagogy
~~Mentoring~~
Being helpful in the moment (coaching)

- We're going to talk about a specific scenario **(click)**: you're **sitting next to someone** and **they need your help** with *their* code - They don't just want you to *fix* their code **(click)**, they want your help growing their coding skills **(click)** - They *might* need your help again later, but this relationship might be temporary **(click)**: we're focused on the learning moment we have right now - What I won't be talking about during this talk, is *Python* **(click)** - I will talk a little bit about **(click)** teaching itself... but not very much **(click)** - And, I've called my talk "meaningful mentoring moments", ... I'm not *really* going to talk about mentoring **(click)**, at least not the way that word "mentoring" is *usually* used - Mentoring is *often* be a big picture, long term mentoring relationship: but my advice here will be focused *primarily* on helping **in-the-moment we have right now** **(click)** - So instead of "mentoring", you can think of this more like "coaching" **(click)** - ... - There are three big topics we're going to discuss. - ... - The first one...

Be a Learning Ally

You're not the star of the show

Teach, don't tell

"You learn by doing"

- When I hold a Python training session, whether at a conference or for one of my clients - I almost always *live code* as I teach - And I'm always tempted to *write code out* and then *explain* it, but that's not teaching **(click)**... that's telling. **(click)** - I don't want you to tell; I want you *to teach* **(click)** - You can do that by encouraging **active recall**: that's the act of retrieving information from your head - ... - We **don't learn** by trying to *put information into our heads* - We *learn* by attempting to retrieve information *from* our heads - *(pause)* - I'm sure you've heard the expression "you learn by doing" **(click)** - *(pause)* It's true. - The reason it's true is that **doing** requires the act of **retrieving information from our heads** - You don't learn by consuming information, you learn by retrieving it: it's the doing that makes the learning stick - ... - This is tricky because *doing* is **intimidating** when you don't yet *know* what you're doing. - You can help your learner by **encouraging them**...

Encourage making mistakes

Encourage experimenting

"I don't know, give it a try."
"What have you tried so far?"

- To make mistakes - Making mistakes involves a *process* of *considering possible solutions*... - What *might be* a correct answer and which possible answer seems like the next best guess; and then **try it out** - The process of trying, failing, and trying again is a *learning* process - To be clear I don't just want you to just carve out a space where making mistakes is okay - I want you to actively *encourage* **(click)** making mistakes - **mistakes are magical** because mistakes usually involve *experimenting* **(click)** - We **take a guess** and then we **try it out** to validate, or *more often* to **invalidate**, our guess because **most guesses** are incorrect and that's just part of learning - To encourage experimenting you could say things like ... - **(click)** "I don't know, give it a *try*" (which is code for "let's make a mistake together") - Or **(click)** "what have you tried so far?" (which means "what mistakes have you made up to this point") - ... - After your learner has made a mistake (maybe you've even made a mistake together), at some point they will (inevitably) find themselves stuck - At that point I want you...

Don't answer questions

Teach, don't tell

Make the answers sticky

- To not answer any questions... *(pause)* - ...I'm kidding, you actually do need to answer questions **(click)** - Answering questions is an important part of coaching - But I want you to **be careful** when answering questions - It's going to be hard to remember that **you shouldn't be telling**, **(click)** you should be teaching **(click)** - So when you answer questions, you want your answers to be *sticky* **(click)** - For example you could make an analogy - Analogies can be very sticky, especially bad analogies - The **more memorable** it is, the better: memorable moments are sticky moments - If you thought up a dance that demonstrates the way dictionaries work, do it. I don't know what it would look like, but it would probably be memorable. - Make your answers **sticky** . ... - And when possible, while giving answers, it's nice to avoid being the source of information. - ... to not give an answer directly but to go on a learning adventure together... - You can do that by pointing your learner in the right direction by...

Delegate to the documentation

Delegate to Google

- delegating to the documentation - Or more realistically, delegating to Google **(click)** - If you're on a call with a coworker and they ask "why am I getting this error message?" instead of saying "ah ha, I know the answer", you could say "let's look it up" - You may *know* the answer, but looking up the answer encourages your learner to **form a habit of delegating to helpful resources** - *You* are a resource for your learner, but **you're not their only resource** - You want to delegate to other sources of information that are more accessible at 2am... or over the weekend - I don't know about you but while I love answering Python questions, I'd prefer not to answer them in the middle of the night - ... - Making mistakes together is important and looking things up together is important... - But sometimes you really just need...

Rubber duck debugging (ish)

"My code doesn't work"
"What do you expect it to do?"
"What does it do instead?"
"What approach are you taking?"

- Rubber duck debugging is the idea that when you get stuck on a coding problem you talk to a rubber duck - Your rubber duck doesn't talk back to you (at least *hopefully* it doesn't talk back) - Your rubber duck isn't supposed to talk back; it just listens - Your duck doesn't answer any questions, but talking to the duck helps you **elaborate** on your problem which can help you **uncover** ideas you hadn't thought of yet - I don't want you to be completely *silent* like a rubber duck, but I want you to do **a lot more listening** than talking **(click)** - So if your learner says **(click)** "my code doesn't work" you could ask **(click)** what they expect it to do and**(click)** what it does instead and then follow that up by asking them **(click)** to explain the approach they're taking... to **talk through** the problem with you - For you that means less talking and more listening - Elaboration is a great way to learn and you can help with elaboration by **acting a bit like a rubber duck**

Be a Learning Ally

Teach, don't tell
Encourage making mistakes
Be a rubber duck
Delegate to the docs (or Google)
You're not the star of the show

- Being a learning ally means - teach, don't tell **(click)** - Actively **encourage** making mistakes **(click)** - And try to act sort of like a Socratic rubber duck: listen and ask questions **(click)** - Also delegate to other sources of information **(click)**, because the spotlight shouldn't be on you - After all, you're not the star of the show. **(click)** Your learner is. - ... - So being a learning ally is important, but learning isn't just **an intellectual pursuit**. It's also an **emotional experience** (for your learner and maybe also for you). - Who remembers learning a new technology and not having **any idea** what you were doing? - Your learner may be **living** that moment, maybe not all the time but probably *some* of the time - Regardless of how secure or insecure your they feel about what they know and don't know... - They're going to be displaying *a lack of knowledge* to **you**, over & over (if you're doing your job right) - ...They're probably going to feel pretty vulnerable - So it's very important...

Build Trust

Be Vulnerable

Telling bad jokes
Making mistakes
Saying "I don't know"

- There are a lot of ways to make yourself a bit more vulnerable - For example, when I'm teaching Python... - I often make bad jokes **(click)**. They're not usually not very funny, sometimes they've even a bit absurd - That breaks up tension a bit, but it also makes *me* a little bit more vulnerable - I also make mistakes **(click)**, sometimes on purpose... most of the time on accident, partly because I'm live coding and you can't live code *without* making mistakes - But when I make a mistake (even if it's on purpose) I never ever say "I did that on purpose to test you" - I want my learners to *feel* my fallibility: it helps them *more* than telling them that I made a mistake to test them - Another big way to be vulnerable is by saying *"I. don't. know"* **(click)** - I don't know, but **let's try it out** - Or... I'm not sure, **let's look it up** - Admitting you don't know is important for building trust - ... - These are just 3 ways to be more vulnerable - And vulnerability is a big way to build trust... but it's not the only way - Another big factor in being trusted is **considering the way you that speak**

Speak Deliberately

"What does this do?"
"What will happen when we run this?"
"What do you think will happen when we run this?"
"What do you think might happen when we run this? What's your guess?"

- Here are 4 ways to ask almost the same thing... - **4 Clicks, slowly** - Which of these is the most **welcoming**? *(pause)* - I would say probably number 4: it's long and awkward but it's most clearly in the realm of *guessing* and *experimenting* rather than *knowing* - Those first and second questions sound a bit like a **pop quiz** - Active recall is how we learn: so you *do* want to quiz your learner, but you don't need them to **feel like they're being quizzed** - There's no need to increase the intimidation factor by adding the feeling of being tested - You want to invite your learners *to guess* and *to make mistakes* by using welcoming and inviting language, not confident or assertive language - *Confident* and *assertive* language has its place, but you'll do much better with *welcome* and *inviting* language when you're trying to encourage guessing - ... - I want you to think a bit less about what you're *saying* and a bit more about how what you're saying *might be heard* - To that end, I want you to be **encouraging**

Encourage, don't alienate

"So obviously, ..."
"Of course, ..."
"Oh it's easy, you just... "

- There are a lot of ways you can alienate you learner (in big ways and in small ways) through the words you use - Here are some problematic phrases I've often caught myself using... - "So obviously" **(click)**: many things are **not obvious** when you're learning - If you're *talking about* something, it's *not* completely obvious - "Of course" **(click)**: this one's a bit more subtle... when you're new to something, there often aren't very many "of course" situations because (again) many things aren't yet obvious - "It's easy, you just" **(click)**: it's easy for you, it's not easy if you don't know it yet - What's in your head, may not be in your learner's head - Your learner doesn't yet know the same things you do, because you're probably further along in your learning process - ... *(breathe)* - ... - This next slide is the scariest one because it could be a big barrier in your effectiveness as a mentor or a coach

You must believe in your learners

- If you don't believe in your learner's ability to improve, they are less likely to improve their skills - Who has heard of the growth mindset? - If you adopt a growth mindset you believe that through directed effort, you can and you will improve your skills: that your skills aren't fixed but are expandable - The interesting thing about the growth mindset, is that... - You're more likely to learn if you adopt a growth mindset: you're more likely to grow your skills if you believe in your ability to do so - And it's hard to believe in yourself if the person who's coaching you doesn't believe in you - Your learner is starting from a *baseline of understanding*: you can't judge that baseline, you just **have to believe** that they'll build up from where they're at right now - And you need to give your learner the impression, explicitly or implicitly, that you believe in their ability to grow their own skills

Build Trust

Be vulnerable
Speak deliberately
Encourage, don't alienate
Believe in your learners

Be a Learning Ally

Build Trust

???

Slow Down

Take things one step at a time

A non-existent (misspelled) function being called
Some code that's poorly styled, but syntactically valid
An error in understanding of the technical requirements
A syntax error that's stopping the code from running

- Let's say your learner says: "my code doesn't work" - They show you the code, and you see 4 things: - **(click)** A function that's improperly named - **(click)** Code that's a little bit ugly, but it works - **(click)** Something that seems like a logical error: a misunderstanding of the problem you're solving - **(click)** And a syntax error: something that stops the code from running at all - *(pause)* ... - Which one of these do you focus on first? What do you think? - ... - **This actually is a trick question**: it's a trick question because you want to focus on whatever is currently *hanging up* your learner - Code style is *probably* not hanging up your learner because if they have these 4 problems, they're probably not asking about code style **(click)** - Code style is often a topic that you can leave for another day: talk about it at some point but if you have these 4 problems code style is not your top concern - The thing your learner is probably concerned about is **that syntax error**: **(click)** your learner will probably notice that first because Python will notice that first - The most important *right now* is the one thing you should focus on next - What that *one thing* is depends on what your learner is most concerned about right now - You don't want to distract: so just focus on *the one thing* that's important *right now*. And then stop. - *(pause)* - *The rest* can come later.

Reflect

- You're going to be better at knowing what to focus on next if you can *empathize* with your learner and imagine what your *they* might be feeling - To accomplish that you can slow down, and reflect **(click)** - When you speak, *question* **what you're saying**, **why you're saying it**, and how it might be heard - ... . ... - Reflecting on your actions and words *in-the-moment* **can** be distracting... I don't want you to get hung up on constantly analyzing your actions in the moment - But you should try to find a way to carve out some space for yourself every once in a while to *marinate in the moment you're in* - Think about what it is you're doing, what you've just done, and where you might be going next - *Reflection* is a very *important* part of learning, and *you* are also learning

Learn About Learning

- Another thing to consider doing, is learning **(click)** about learning - There are *a lot* of folks who write about learning best practices the same way developers write about programming best practices - These best practices will be useful for you because *you* are learning - But it'll also be useful to share these concepts with your learner - For example you can... - Talk about the growth mindset: that is the fact that believing you can grow your skills actually *helps you* grow your skills - And you can talk about the fact that **you don't learn by putting information in your head**: you learn by **retrieving information from your head**. The information retrieval process is where learning actually happens - A discussion about learning might be a *moment* for you, but *a lifetime* for your learner - Improving your your learner's ability to learn will also impact their on-going programming career as well

Fake it until you make it

Adopt a growth mindset

- "Fake it until you make it" - I don't really like this phrase: it sounds a bit insincere or maybe demeaning - The connotation seems a bit off to me... - But there is some truth to this idea - Faking it until you make it, is kind of related to adopting a growth mindset **(click)** - If you *slow yourself down* and think "if I were a *really good* mentor, what would I be doing right now", **you're faking it** - You're acting deliberately: you're pretending - But you're also *practicing*: which means you're learning - So eventually you you won't need to fake it because it'll be intuitive - *Faking it* is just another way of talking about the growth mindset - ... - Many mental abilities are learned skills - **Thoughfulness** is a learned skill - **empathy** is a learned skill - **friendliness** is something you can learn - I am a friendlier person than I used to be. I've been faking it for years and at some point I internalized a bit of friendliness. - Lots of things seem like they're inherent parts of our personality: but many things can be changed if you put in the right kind of effort - If you identify a trait in someone else that you like, steal it. It's yours. You can fake it until one day you also have that trait.

Slow Down

Slow your thinking, speaking, and acting
Take things one step at a time
Learn about learning
Adopt a growth mindset

Be a Learning Ally

Build Trust

Slow Down

Visit 🔗 https://trey.io/BlackRock22

For recommended resources and Python tips

Ask me questions about:
Python training, teaching, learning Python, anything else

Trey Hunner
Python Team Trainer
[email protected]