Clear as a bell: Sharing technical expertise

Laura Savino at Swift Summit San Francisco, 2016



Laura: Excellent. Alright, let's get into it. Before I became a programmer, my formal training was actually in pedagogy. I spent my first few years out of university teaching English to kids in Korea, and French to kids in Seattle. This is actually a drawing that one of my kids did of me. That's me on the right, I’m the French teacher. That's my pet lion on the left. But fast forward a few years after my teaching days, and I'm married to a programmer. I was an Excel power user. I got really into formulas, eventually into VBA macros and that was kind of the beginning of the end of my life as a non-programmer. I asked my husband to teach me programming, and he hands me the K&R C book so I can read it on the bus on my way to and from work. I realized that even though I had this incredibly smart, knowledgeable, patient person who was willing to teach me everything he knew, if this was ever going to work, first I was going to have to teach him how to teach.

I want to start with actually a brief exercise, because this talk is about teaching, and you didn't think I was going to let you get away without doing in-class exercises, did you? I want you to think about the last time that you had information that another person needed, the last time that you taught. It could be sitting down and introducing a particular Cocoa API to an Android person who's just joined your iOS team, or a brown bag that you gave at work, or even just explaining the build system that you've set up to the rest of your team. Then think about; how well did those people retain it? How can you tell? We'll come back to this part.

Studying education is not new, right? This getting better at passing skills from one person to another has been going on for a good minute now, and people are constantly trying new things and ways that are creative and also rigorous. Education as a field also has its share of smack talk and controversy, but this talk today is going to be focused on uncontroversial sorts of basics, the skills that teachers develop and then quickly start taking for granted. We're going to go beyond clear explanations too, because yeah that's important, but learning goes way beyond just understanding someone's ideas while they're standing in front of you explaining them to you. That's the angle that I'm pushing in this talk. How do you get people to go from being aware of a thing to being able to use it and apply it well, so it sinks in and actually changes their behavior?

Let's get into it. What are some behaviors of teachers that you might be able to apply yourself so you aren't doing the equivalent of handing somebody the K&R C book and wishing them a heartfelt good luck? First, teachers make sure that students think, because the goal of teaching is getting information really lodged into somebody's brain. Now, there's this pattern of regular human conversation that follows a certain rhythm, right? There's a question, like da-da da-da da-da da-da, and an answer, da-da da-da da-da da-da. Da-da da-da da-da da-da, da-da da-da da-da da-da. But if you ask a student then, "So how would you transform this array?" and they don't immediately answer, it is so tempting to jump in and answer you own question. Don't.

Teaching isn't about just having some particular facts spoken out loud. It's not about having, oh I want to make sure that the air molecules vibrate in this very particular pattern. No, it's to get a decision from the student's brain. So a rule of thumb that teachers use is to ask your question, and then count to seven before you say anything else. It feels like an eternity, but to the person trying to answer the question, their brains are going to million miles a minute. They need time to think. So you, when you're' asking someone a question, pipe down long enough to make sure that they get that thinking time.

I'm also a volunteer with App Camp For Girls where we introduce middle school girls to making apps in Xcode. We have a hard and fast rule, no pointing. You can imagine how hard that is in Xcode, right, when you want to say, "Click here and here, and then there, over there"? But our goal isn't for the girls to be able to click at exactly the tip of somebody's index finger. What we end up doing is describing in words, "Okay, see that row of three buttons on the top of the screen and the one in the middle with the overlapping circles," because the more the student's brain is involved in working out the problem, the more likely they are to remember it next time without you.

You might be skeptical at this point thinking like, "You know what? The build is broken. I went to ask the build engineer how to fix it and so I can get this critical code pushed, and they said, 'Well, how do you think it should work?' And then I set the building on fire." Now, you can work around this though. If somebody comes up to you with a question that reveals some gap in their knowledge, just ask them, "Hey, do you want me to try to teach you or do you want me to just tell you?" Because they're also a professional, right? They care about learning the skills that they need, and if this is the right time for an informal training session, they will let you know. First get permission to establish that student-teacher power dynamic just for a minute, and people will be so much more receptive. 

Since I'm going through this at lightening speed, there's a lot that I'm going to be leaving out here, so I'm throwing in some extra search terms every so often to get you started if you'd like to dig a little bit deeper and find out more. For a starting point on how teachers let students think, search for “student-centered learning”, things like “active and passive learning”.

Another behavior of teachers, they will tell you why the thing matters. A question teachers get all the time but that grownups usually stop asking out loud, "When am I going to actually use this?" People get really efficient at tuning out the bits that won't be relevant to us. Like you saying, "But I think this is going to be really cool and helpful," that is not actually always enough to convince somebody to spend the cognitive resources and time to learn something new. I know you want it to be, but attention is finite and people get to choose how they set their own priorities. Someone might listen to your explanation politely and nod at all the right places, but that is different from turning on their brains to actually engage. So give them a hook. Tell a story, a real one about a time that somebody made a different choice with dire consequences, or use really concrete examples the way Nate did this morning. We are all going to picture legos now for whenever we see containered sorts of protocols. It turns out if you can tell people a vivid story so they can picture it clearly, they'll believe that that situation is more likely to come to pass. It is a really awkward property of human brains, honestly. It makes us bad predictors, but you can use this power for good. When you've decided something's important, a vivid story will help your case.

Also on why it matters. Introducing some new framework, or design, or API, or whatever, into your app, it's never free, right? This extra cognitive overhead alone can be pretty serious, so if you're proposing a solution for say network latency bugs, make sure the team agrees that network latency is actually a problem first, or else they'll remain convinced like, "Well, I'm never going to need this. This isn't even a problem," and they're going to ignore the things that you're presenting completely. 

So resources. “Thinking Fast and Slow”, I would like to be the 48th person to recommend this book to you. This is the book that talks in detail more about how vivid examples affect peoples' ability to predict likelihoods. This “Four-Phase Model of Interest Development” is a truly fascinating study on how people develop sustained interest, especially in educational settings.

Teachers also have explicit learning objectives for a thing that a student will be able to do as a result of this session. There is a whole body of literature on how to decide on learning objectives, but the three minute version basically boils down to; get really specific about what people will be able to do. It is not a plan for how to organize the time to say, "Spend 20 minutes on subtopic Y." No. It's about what ... Sorry. Yes. It is about what in very concrete terms someone will be able to do that they couldn't do before. A teacher would never make a learning objective like "Learn core data better," any more than you would make a user story that was, "Make login better." It's not specific enough. When I was teaching French to the little ones, I might decide at a high level maybe it's a good time to learn numbers, but I wouldn't plan a lesson saying, "Cover the numbers zero to ten." No, I would say instead, "Students will be able to exchange phone numbers with each other." Now, this will help your focus move from something like, "Cover protocols," to, "Okay, students will be able to decide whether a group of functionalities should go in a protocol and defend their choice."

Now, this is a tough mental shift to make, so let's practice. Think of that technical concept that you wish people around you understood better. Maybe it's that situation you thought of earlier, or maybe it's something new. Imagine you have an hour to try to teach it to them. Given this interested audience, what are two things that you would want them to be able to do at the end of that hour that they couldn't do before? Below here, this is a list of verbs that I took from Bloom's taxonomy, which is 60 years old but still a good list for starting with specific actions. 

To find out more about learning objectives, search the “learning objectives”, “outcomes”, “learning goals” versus “performance goals”, which are different. And there's “Bloom's taxonomy” again which will give you a whole history of being worked and reworked and sometimes totally rejected, but meanwhile it's a pretty good list for that initial set of verbs.

Another critical behavior of teachers, they bring practice materials. We develop skills when we exercise them, right? So teachers bring materials for students to chew on. These are some of my old French teaching materials with my pet lion in the middle there. Now, there is disagreement about how students should engage with content, but there is no disagreement about whether students should engage with content. No one is advocating that purely passive reading or purely passive listening is the best way to acquire a skill. So give people something to practice on. I teach a git workshop. Writing code is hard. Learning git is also hard. When you're first learning you don't have to do both at the same time, so what I do is bring a git repository that's full of ridiculous poems that has properties that allow us to have merge conflicts and all the rest, but if somebody hits git checkout at the wrong time, they won't be heartbroken when they lose their newest acrostic poem.

Your materials don't have to have to be elaborate. You don't have to go and get like a series of tubes to try to get at the principle behind reactive programming. They might just be questions you thought of ahead of time that lead people to some relevant practice examples, or maybe you bring some raw data to manipulate. If you're going to be teaching some functional programming concepts, instead of saying, "So write an array and transform it, I'll wait," say, "Okay, here's an array. See if you can transform it into an array that has these properties over here." When you're coming up with these examples, if you can include any intrigue, any suspense at all so people are thinking, "Oh yeah, I wonder what would happen if ..." now you've got people engaged.

You might get some pushback though about these blatant in-class exercises. Like you go into your brown bag or instead of setting up Keynote or your live coding demo, if you ask everybody to get into pairs and use core graphics to shade and mirror an image, you might get, "Uhh, this feels like school." But you know what? This is the good part of school. This is the part that makes it easier to learn, so that's basically like saying, "Uhh, this feels like something that's specifically designed to make learning easier. Can we not?" Meaningful interaction builds people skills. We're not looking to get people able to fill out a crossword puzzle with language keywords. We're looking to get people more effective with their tools, and that only comes with practice. No one should shy away from getting their hands dirty.

Let's take another minute for that skill you want people to develop, that objective from earlier. What could you prep that would give them some focused practice? Maybe some hands-on practice in your existing app? Is it something that could fit in a Playground? Are there samples you could take from open-source? Just get that clear in your mind. 

For resources, “scaffolding” is one of my favorite words. This is talking about creating materials that support students to do more challenging work without actually just chucking them straight into the deep end. “Guided learning” will lead you into some more of these controversies in education, and “worked examples” are a type of material that can help jumpstart students' learning as well.

Teachers change things up. Let's assume just for the sake of argument that your colleagues really want to be there, that they really want to learn this thing from you. I don't care how charismatic you are, it is hard to listen to somebody for an hour straight. People who teach to kids use a rough rule of thumb to decide about how often to switch activities, which is that kids will pay attention for a number equal to their age plus two in minutes. When I was teaching French to three and four year olds in a 30 minute class, I would plan six or seven different activities. Unless everybody's actively working on something, change things up. Change things up so people stay fresh, because it is so hard to passively absorb information on and on. Now, you don't have to break things up dramatically. You don't need to stop and do a line dance about a keychain API, but maybe part of your session is you're going to lecture, and part is people working on producing some small thing, and then part is reviewing and judging some other examples of this technique. Swift Summit, by the way, is doing a really excellent job of this with these short sessions, and as a very late speaker in the day, I want to say thank you to them for doing this so that you all have stayed engaged the whole day through.

Another behavior of teachers, they are all about making their students better. Going back to the learning objectives, a teacher doesn't write, "I have to cover ...," or, "I have to be ..." No. They write, "Students will build. Students will be able to differentiate." It's funny because a lot of peoples' anxiety about public speaking comes from, "Uhh, but what are they going to think of me? They're all going to be watching me, and what ... ugh." But flipping this on its head, as a teacher, as a speaker, your work isn't about you at all. You want the students, you want the audience, to be able to do a thing that they couldn't do before. The stakes are higher now because if a whole room full of people, if they all still can't use protocols effectively, that's a big deal. But as a presenter, yeah I regret that I didn't do a better job, but I don't feel that crippling useless shame, because my presentation was never about me. "Uhh, my explanation didn't work." There's kind of like a rueful head shake that goes along with that, but it also becomes data for next time. But thinking, "I looked really bad up there," that makes me want to hide in a corner and like throw away my lapel mic.

A lot of my thinking here comes straight from Kathy Sierra, who you may have known from her writing as Serious Pony. She says it really, really well in her essay “Presentation Skills Considered Harmful”; "The best presentations aren't about what a presenter does, but what the audience experiences as a result." Please, I want you to expand this beyond the formal presentations too. If you've got a chance to mentor a junior developer or an intern, if you think more about helping them learn and less about kind of showing what an expert you are, they will learn more and faster and contribute better to your team. I was really inspired by an interview with Kathy Sierra that doesn't seem to be available online anymore, but these publications of hers get at the same ideas.

Teachers also look for feedback about whether their lessons worked. There's no assumption that just because these words were said out loud that they were internalized. Ending a lesson and then moving on with no assessment at all, it's like submitting a pull request without running the code. Like, "Well, I wrote it. That means it works, right?" You don't have to sit down though and say like, "So what did you learn?" because that ventures into this kind of patronizing territory that gets all of our hackles up. But honestly you don't even have to tell people that you're evaluating your lesson's success. You can observe their next output that's related to whatever it was that you just tried to teach. Does it show signs that they remembered and used the stuff that you tried to explain? This is where specific objectives will support you again. If you've got some idea of what it looks like when someone has the skill and what it looks like when they don't, your evaluation step pretty much writes itself.

One quick way that I'll often get real-time feedback from students in a technical workshop is with a quick like thumbs up/thumbs down temperature check. "So how confident did you feel about that last section?" This is a million times better than that quick, "Everybody with me? Okay." Because only loud people answer that, right? That's like a pseudo-interactivity. But asking everybody to make a silent gesture, and peer pressure works, everybody in the room will do it, then you get real-time feedback from every single person in the room. As a side note, nobody will ever give you a straight thumbs down. That feels like booing and that's not a thing that professionals will do to each other, but if you see one of these, that means people are extremely confused and you need to try your explanation again. It did not work. 

These are some words that educators use to talk about this: “evaluation”, “assessment”. Reading about test design is fascinating for seeing how people decide whether a particular test, a metric, is actually evaluating the thing that they care about.

Finally, all excellent teachers are experienced teachers. Before their first teaching job, certified teachers go through a ton of training. There's a bunch of theoretical study, there's observing classrooms, there's being a student teacher where they get hundreds of hours of hands-on experience supervised by somebody much more experienced than they are. Even with all of that, a common refrain from professors when I was studying was setting this expectation, "Okay, for your first year, at most, maybe, maybe, we would be pretty good, but we would not be great educators." We've all had the unfortunate experience of trying to learn from an unskilled teacher. In the worst cases, we get turned off the subject entirely, and sometimes if the subject was something that was complex, a lot of people end up making negative personal judgements about themselves, right? They decide, "Uhh, I'm not smart enough for that. That's not how my brain works. Too bad."

A professional teacher cannot get away with saying out loud in class that they're unskilled. "Yep, sorry kids. I don't have a good explanation for ideal gas laws, so this lesson's going to be rough." But you, you are almost certainly not a professional teacher, so if you're about to try to teach a thing but you've got no evidence that suggests that you are any good at teaching that thing, you can start off with a caveat right off the bat. "Hey you know, if this doesn't make sense the first time, don't worry. I'm not actually sure how best to explain it, but I'll try." And meanwhile maybe, "Here's some resources that I use to practice it myself." Or, "Here's resources that I've heard other people found helpful because I learned this concept so long ago that I've forgotten what it was like to even struggle with it." 

Searching Google Scholar for articles about “expert versus inexperienced teachers” is fascinating. Clear and memorable teaching is a skill that takes a lifetime to develop.

But meanwhile, we all teach, right? Whether it's in obvious ways like standing up with slides and demos, or in subtler ways, maybe telling coworkers there's a pattern you'd really like them to use and you've linked them to docs or projects that you've selected that you think will help them learn this. Or maybe you're sitting with an intern and you're walking them through disentangling a function to kind of pull out the side effects. We all teach, because we all have skills that we want the people around us to pick up on.

Hopefully you all just learned today a whole bunch of new skills and you're going to learn a bunch more tomorrow. We all teach and we can do it better. Next time you're sharing knowledge with your colleagues, whether it's formally or informally, borrow some pages from professional teachers. Who knows, maybe you'll develop more confidence in your skills and it'll turn from you presenting a bug report at a white board to teaching wide audiences. But all that aside, more importantly, learning from teachers and teaching best practices will make you more efficient at passing on your skills that you care about the most to the people that you care about the most. Thank you.