Made by
Made by
Erin McKean
Fresh from her DevRelCon London 2017 opening keynote, Wordnik.com founder Erin McKean sits down with Peter Cooper to talk teachable moments in development, and why the best learning is served encased in real-world examples.
Peter: Hi, I’m Peter Cooper and I’m here talking today with Erin McKean, who works for IBM and many other things besides, including being a lexicographer in your spare time, and today, you did a really good talk about how to context in developer relations and how to, this idea of, that when you gave examples and demonstrations, you think about what the context of the user is and try and dwell within that context a bit more and help provide your own content by providing kind of what you called, was it “teachable moments” or “learnable moments”?
Erin: Teachable moments.
Peter: Yeah. So, the thing I really liked about the talk was when you talk about salient features of a product and you have this example of a mug with a slogan on it…and you can get a mug without a slogan on it, but it’s kind of not right until it has the slogan on it…and I just found that really interesting because also in that I would often think about, when I’m communicating with other developers, is, like, “What is all the…” I guess I wanna say “window dressing,” but I don’t mean that in a bad way. Kind of what is the thing that makes the set look like something where these people want to perform, essentially?
Erin: Right. Like, what’s the differentiator, right? Like, what makes this useful or important? And so there’s like a couple of different levels. So first of all, thank you, I’m glad you liked the talk. But thinking about a piece of technology, like, what’s the bare minimum functionality? And then what makes something useful or important? And then what makes something implementable? And I think these are all different aspects of demoing or giving a tutorial because I can show you, you know, I can show you how to call an API, but can I show you, like, what use case it really works in? And then can I show you, like, how to really integrate it into what you’re building? And if you don’t have all of that, then your tutorial’s not gonna be as useful as it could be.
Peter: So this is a bit like when you might write a programming book, for example, and people have that classic example of object orientation. It’s like, “Right, we’ve got a class that’s called ‘animal’ and then we’ve got, like, a monkey and…” Like, and I think people, perhaps, are trying to do what you’re saying by doing that. They’re not just calling it “foo” and “bar” and everything, but the fact is they’re usually completely useless examples, so is that just as bad as being completely generic?
Erin: I am a fan of using real data, and I feel like there are so many public and available datasets that you can build examples on that you should. I’m a huge fan of this TinyLetter called “Data Is Plural,” and every week, he sends out, like, five or six public datasets, and, you know, it’s really easy to dump that into a local database or into a cloud service and then build off of that and show real data. And it’s fun. The dataset I like to use the most is the dataset of over 200,000 “Jeopardy!” questions. Because, you know…
Peter: People can relate to that.
Erin: People can relate to that.
Peter: Yeah. It’s interesting, though, because I saw a very prominent JavaScript developer the other day tweet, and he said that when he does JavaScript training, he deliberately avoids any references to anything, and he uses “foo” and “bar” everywhere as his variable names, and I, like, I don’t like that idea. Like, it just…because I lose touch of what that means. It’s so abstract, but he had these people saying, “Oh, no, I agree,” like, because when you’re learning syntax of a language, you don’t want to be learning, like, a problem domain and a language at the same time. Now is the problem…What they’re thinking about there is they’re thinking of a problem domain as being something that’s kind of alien for the learner and they should be picking a problem domain that is in their, you know, wheelhouse, as it were. Is that the issue?
Erin: I think so. I find it very hard to learn from abstract examples, and I think most people learn better through analogy and through real examples. But then I’m a little biased because I came into coding from a very specific problem domain and I tend to make all my examples kind of around that domain. But I think it’s perfectly reasonable if you know that for a particular product or service that there are four or five different use cases to build tutorials in those domains.
Peter: Well, you mean, like, if you’ve got the same content, you could almost re-style it to fit these different areas.
Erin: Yeah. Like, if you have a product that could be a dessert or a floor wax, right, you say, “Oh, okay, well, here is my floor wax demo,” and, “Here is my dessert demo.”
Peter: That makes sense.
Erin: Yeah.
Peter: Yeah, cool.
Erin: That feels so good.
Peter: So I hope you enjoyed the event here so far. It’s been an interesting day so far. I really enjoyed…not just yours, everyone’s. How’s it been?
Erin: I have learned so much. I have taken, like…I have a little notebook, I’ve taken a ton of notes.
Peter: Yeah, so have I. I’ve got one here as well.
Erin: Yeah. I feel like…there are very few places where developer advocates and developer relations and experience people can, like, all get together and learn from each other, and this is, like, the best place to do that. Because, like, we don’t have a guild or a union.
Peter: Right, yeah.
Erin: Right? Like, we’ve gotta have a place where we can share knowledge.
Peter: Yeah. Unfortunately, we’ve gotta wrap it up now, but…yeah.
Erin: It’s always a pleasure talking with you, Peter.
Peter: Exactly. You, too. So thank you very much, and obviously, if anyone’s watching these online, come along to DevRelCon when it’s on next. It’s all around the world. It’s a good event. I’m sure we’ll be here again at some point.
Erin: I hope so. Thank you.
Peter: Cool, thank you.