Badass: making users awesome

Carmen: Hello and welcome to the DevRel Book Club. I'm Carmen, and I'm joined by Matt to my right. Hi Matt. How are you?

Matthew: I'm very well, thank you. How are you, Carmen? I am very well, thank you.

Carmen: Very excited to be recording another episode with you, Matt today, and to have our special guest join us. We've got Erin McKean joining us all the way from Portland, Oregon. Hello, Erin. How are you?

Erin: I'm fine. Thanks for having me today.

Carmen: Please, Erin, we're so excited to have you. Why don't you tell us a little bit about yourself?

Erin: So I'm Erin McKean and I am right now in Portland, Oregon, and I'm the lexicographer behind the Wordnik website, which is, I like to joke, the biggest online dictionary nobody's ever heard of. It has an API and a data set for game developers. And my day job, which is super fun, is I work on open source documentation for the Google Open Source Programs office. So I help open source projects, understand and use documentation tools like Doxy, and I also help Google's open source team have documentation both internal and external.

Matthew: I think it's worth noting as well that something that affects pretty much every API interfacing developer's life came out of Wordnik too.

Erin: Oh yeah, sorry. Yes. So if you've used the open API spec the spec, formerly known as Swagger. That was developed by my coworkers early on at work, Nick, Tony Tam and Zeke Anos.

Carmen: Wow, that's amazing. Yeah, definitely something royalty.

Erin: Oh, well that's the joy of open source, right? You get your return and the happiness of other people who use the stuff that you worked on. And yeah, in my not so spare time, I run the Semicolon Appreciation Society.

Carmen: I'm sorry, you piqued my interest. What's the Semicolon Appreciation Society?

Erin: It's just a place for people who appreciate semicolons. Mostly it involves stickers.

Carmen: Love it.

Erin: So you can rep your semi colon love.

Matthew: And we haven't touched on dressmaking and novel writing yet either.

Erin: Oh yeah. So I make a lot of clothes and I used to blog about it much more regularly at a blog called A Dress a Day. I never made a Dress a Day that is a common misperception. And then I wrote a novel that's also about dresses called The Secret Lives of Dresses, and then I wrote a book that was a field guide for dresses called the hundred Dresses. Yeah, so my spare time, I think a lot about dresses as well as semi.

Carmen: That's amazing. Wow. It's always such a joy to meet people who are so multi multifaceted and multi and have lots of interests that they seem to intersect if I have their intersections, if that's not too broad an assumption, I hope.

Erin: Yeah, I mean, I think doing any kind of craft with your hands I think is really relevant to people who work in Devereux because it really puts you back into the process. I feel like a lot of times when you're expert enough to explain something to someone else, you often gloss over the tricky bits because they're not tricky to you anymore. But every new pattern is a new opportunity for me to find another tricky bit. Right now I'm working on some patterns that evolve a lot of buttonholes, and I've been steadfastly avoiding buttonholes for a while. I can do them, I just don't enjoy them. But I was like, Hey, maybe it's time to take another look at Buttonholes. Right.

Carmen: That's fascinating. This is something that I was actually feeling just yesterday. I don't want to go off on a tangent too much. My friend Jess and I are running a free JavaScript bootcamp and web development bootcamp around the world, and yesterday we were doing a concept in JavaScript called the Prototype Chain, teaching this to Newcomers, which is a doozy when you're first, and when I say first, when you're first exposed to it, I think every time I'm exposed to it, I'm like, oh yeah, there's that. I need to wrap my head around this all over again, which correct me if I'm wrong, is kind of what you feel with Buttonhole.

Erin: Yeah. They're kind of tricky to set up that when they go bad, they go really bad. You can't recover very easily from a bad buttonhole. You've already cut the fabric. They're really tricky to unpick. So yeah, I think there are a lot of similarities to the Prototype J, in fact, when I think about it.

Carmen: Yeah, yeah. Well, sorry to take us off tangent. Let's go into the book that we're going to be discussing today. Now, Erin, you've brought to us the book, which I've got here, badass Making Users Awesome by Oh, look at that. I love it by Kathy Sierra. Don't want to go off too much, but this is actually one of the first books related to DevRel that I've ever read when Joe Nash very kindly sat down with me and gave me some tips as to how I could get started in my first role. And he said, you must read this book. So having it come up again is amazing. I'd love to hear Aaron, why you chose this book for the book club.

Erin: I really love this book, and first of all, it's astonishingly clear and easy to read. I think you can tell when someone's really the master of their material when they don't try to make it complicated to make themselves look smart. This book is super clear,

Erin: Also the first time I read it, which was probably right after it came out, I think it came out in 2015, and when you see those optical illusions, which it could be a duck or it could be a bunny, and first you're saying, oh, that's only a duck, and then you see the bunny and you can never unsee the bunny. So there's something that Kathy Sierra says in this book that once I read it, I could never unthink it, which is that she says that users don't recommend things because they like the product. They recommend things because they like their friends. You're not doing a favour to the product when you recommend something because you like it. Right? You're doing a favour to your friend because you think their life will be better if they know about this cool thing.

And as someone who's probably on the edge of unpleasantly enthusiastic about stuff, if you encounter me right after I find something new that I really like, you're going to hear about it because I like you and I'm like, this is awesome. It's going to change your life, blah, blah, blah. And when I first read that, I was like, oh, right. Because people spend so much time trying to make their products better against some neutral bloodless checklist feature by feature model of what makes something better when you should really be thinking about what's going to make someone want their friends to use this. And that's her whole thesis is that you don't make awesome products, you make awesome users. A product that nobody uses can't be awesome, even if it's clinically awesome, if it checks all the boxes. If you're like, well, I have a 15 point awesome checklist and it checks every one of these things, that's not true unless anybody uses it.

Matthew: That's one of the reasons that I am a little uncomfortable with the original version of NPS and particularly how it seems to get used in DevRel to show some kind of progress within a devel programme. And I think actually, you can't just dress up that very organic process into some numbers and make it look scientific and then say, well, this is a key measure without also taking into account all of that human stuff that goes on.

Erin: I think net promoter scores, it's neither net nor promoter nor score as the old joke goes, right. I often get asked if I'm going to recommend things when I don't know anybody else who wants to use this thing. How many people do I know who want to use a preferred employer organisation?

That number is vanishingly small, I'm not going to recommend it to my 22-year-old son. Why would I do that? That makes no sense. So you have to understand the context of the user as well. And I think also you have to be like, well, I don't really know anybody else's life. I can make a suggestion, but they're the people who have to understand whether or not it works for them.

Carmen: Yeah, and thank you. Thank you all for explaining Net Promoter Score. Was it? Yeah,

Erin: I think that's what NPS stands for. I try not to think about NPS, so

Carmen: That's fair. I have to admit, I hadn't heard of it before. You're lucky

Matthew: The number range where it says, would you recommend this to friends or family? And they basically consider anything below I think an eight or a seven as being abject failure. And there are reasons, but I don't think they're particularly compelling reasons. But anyway, that's what NPS is.

Carmen: Thank you. It's funny, what I found astonishing about this book is that, and I think Aaron, I shared a very similar experience where there are books that like this, that sort of, once you read them and you have that epiphany where it puts a thought, words to thoughts that never escape the mindd, again, I found that this was a journey of that. Sorry.

Erin: No, and I think that I love that you brought up words to thoughts because another thing that I love about this book is that she explicitly says not to discourage the use of jargon when talking about your thing. And obviously as someone who loves words of wants all the words to have a happy home. I 100% agree with this because if you deny your users the opportunity to learn the jargon of the field, you're basically infantilizing them.

Imagine if you got really into a sport, I don't know, maybe the one y'all call football and you're like, okay, well, who's that person that runs around towards the front all the time and does a lot of the kicking and tries to get the ball into that big thing with the other guys standing in front of it? But if you had none of the terms for the players and what they were doing, that really just takes away from your enjoyment. It takes away from your feeling of mastery.

Carmen: It's funny because I literally last week was having this discussion at work where on the one side we had it was whether not to have a glossary in our documentation. And I like glossaries. I like having a list of words that I can refer to, refer back to. And we were going back and forth on this on whether, for example, our terms should be self-describing, which for all intents and purposes is a noble pursuit maybe.

But it's difficult because I mean, just when you take one step outside of the English as a native language realm, you run into some trouble. So I found the fact that we had a, and I think it was an entire section of the book dedicated to jargon. I literally took that whole section copied and pasted it into my work like, Hey, look at this. This puts again those words to thoughts really well. So I'm glad you brought that up. I was going to bring it up.

Erin: Well, I should point out that as lexicographer as someone who makes dictionaries, I'm contractually obligated to say that words are not otherwise me and all my friends would be out of work. But I think having a glossary is an inclusion issue, especially for people who don't have whatever language your documentation is written in as their first or primary language. It's also a matter of context.

An example I use all the time is if I say the word toast without context, you do not know whether you're getting a glass of champagne or a piece of bread with jam on it. Without context. Things don't have meanings. They have possibilities, but they don't have actual meetings. Context drives the meaning. And I also think in this day and age of infinite hyperlinks, you can link to things. The people who know it will not be impeded. The people who don't know it, they can click, they can hover. There's no excuse now to say, oh, well, this information exists, but we can't possibly let you know about it because that would be inconvenient and awkward.

Matthew: Isn't there an argument for an on-ramp though? I've read lots of sci-fi books where I've given up very early on because they talk about the plunger and they give crazy names to, or sorry, just alien sounding names to all of the characters, and I'm like, oh, was that character and what device is that and what concept is that? And I get that's a different realm to the one we're discussing, but I've felt the same way reading documentation before when it's my first step into a particular technology.

Erin: I think that's a good argument for the prologue in the science fiction novel and the concept, the concept overview. And then also there's this time honoured as Bob Technique as Bob, the SL goal is a very complicated piece of technology, and if we don't have a calibrated just right, we're going to tear a hole in the fabric of space, which gives you an idea of, oh, what that is. I really like it when people do parenthetical explanations in a positive phrase.

In fact, at Wordnik, we try to collect those, we call them free range definitions, where somebody defines the term in a very organic way. And you see this a lot in high quality journalism. If you're writing about the cutting edge of science or technology or finance or whatever, you're still thinking about a print newspaper and you're still thinking about a low time consumer of that information. So you're trying to organically describe what something is in context as you go along, like looking at early articles about any technology, you will see valiant journalists trying to explain it in simple terms, and sometimes they get it wrong, but most of the time they get it right.

Matthew: This feels like it's taken us into the, let me check. I've got the suck zone. And this is something that's been raised at Dev Recons in the past as well, has been particularly relevant to developers, I think as users learning a new technology or product. Erin, can you just take us through what the suck zone is?

Erin: Well, I feel like we all know intuitively what the suck zone is because we've all felt it. Like if you've never felt the suck zone, then you are firmly in Dunning Kruger territory, and I'm really sorry. But when you know enough to know that you're not very good and to keep trying, and you might, Kathy Sierra has a lot to say about the merits of directed practise. You need to do things where you're not very good and try to get better at them because just doing the same thing in a mediocre way over and over again doesn't get you any better.

Actually, Ira Glass has a really good video about this, about the gap between what your taste wants you to make and what your skills let you make, and how that's very discouraging for people because they have very good taste, which is why they want to be in a particular creative field, but their skills aren't there yet.

So everything they make, they're like, this is terrible. And actually I see that with people who are new to sewing. They want to make a complicated, beautiful garment, and they can't sew in a straight line yet. And so of course they're disappointed with the results, so you have to do the practise.

Carmen: This particular section brought me screaming back to my childhood when I was trying to learn an instrument for the first time, how I sounded in my imagination versus how I sounded in real life. And one thing the book did really well was use illustrations to show what it is that we tend to use as a response to that, which is to have the end goal seem all the more enticing and pulling rather than making that journey a little bit less exhausting.

Erin: I really like how she says, you need to be honest with your users and say, this is hard, because if you say, oh, it's easy peasy, it's a simple matter of engineering, then you make them feel terrible, and your goal is to make them feel awesome and to actually be awesome. And I think Kathy Sierra is mostly writing about more standalone products, but I think very few of us and DevRelwork on things that aren't part of a bigger ecosystem that don't plug in at one end or another to something else that we may have no control over.

And I think it's at those interfaces of deployment, of monitoring, of observability, anywhere that there's an edge or an interface, that's where Thes Zone gets really wide and deep because you think, oh, well, that's not my problem to tell them how to deploy this thing. I just tell them how to use this thing. I don't know anything about your deployment. I don't know where you're running this thing, but that's the hard part oftentimes, and the more that you can tell them or give people guidelines, and also sometimes people just completely abdicate. Any suggestions about running something securely? How many JavaScript examples have you seen where it's like, put your API key here, right?

Erin: Yeah. I would say once a week I get an email from someone who has a Wordnik, API key who's accidentally deflated to GitHub, and I'm like, fine, no problem. I'll reset your key. But I know they were probably following some example that didn't tell them anything about secrets management because it wasn't their job, but that's a big suck zone.

Matthew: It feels as though when we're dealing with developer education and documentation, it's one suck zone after the other. You mentioned that the edges of where products interface and so on is kind of sucks zone multiplied. Have you applied that understanding about the suck zone to your work as a documentarian over the years?

Erin: I think it's really important to understand the user journey. I think everybody who works with me right now is so tired of hearing me say the word user journey so tired because you can't just think about what, and I think that ties in really well with the idea of making users awesome.

Unless you understand what someone's trying to do, you can't put them in a position to be able to do it. And it's easier, I think when you can see a clear handoff between user journeys like, oh, hey, this is the developed user journey. This is the deploy user journey, and this is the monitoring observation user journey. This is the deprecation user journey, which we hardly ever talk about, which is very important for it.

This is the security user journey. See where they all intersect and try to make the transitions be a lot less like falling off a cliff and a lot more like a well-planned highway interchange, right? Okay, here's your exit. There's a lot of great signage here, and we're going to tell you right away that you were just going 75 miles an hour and now you're going to have to go 25 miles an hour. Tell them it's going to be hard. Tell them it's going to be slow.

Carmen: That reminds me of how the book makes that very strong distinction about the context before and after the sell, so to speak, before how before it's about the context and after it's just about the tool.

And the book said something that really resonated with me where they show the marketing website with all the flashy graphics about how you're going to be a great photographer once you buy this camera and then you buy the camera. And you've got this extremely, I guess, for lack of a better term, dry manual that just exhaustively shows every part of the camera and how it works and kind of stops enabling you to be an amazing photographer.

Erin: I actually think this is a place where sewing patterns do a much better job than many developer tools. So you can buy a sewing pattern, it's often a downloadable PDF, and then you go back to the provider of the sewing pattern, and they have a sew along where you can watch little videos of people doing every step. And then not everybody is the perfect size that the pattern is drafted for.

So they have little videos or blog posts about, oh, okay, here's what to do if you're taller than the pattern is drafted for. So a lot of patterns are drafted for people who are five foot seven. I personally am not five foot seven, not even on a good day. And then here's how to change the pattern if you're a little wider or narrower than average. So they sell absolutely the idea of this beautiful garment, and then they support people getting there.

Lots of people have absolutely no idea what kind of fabric is appropriate, so they'll often have pictures of the garment sewn up in different fabrics. Here's what it looks like in a stiff fabric, here's what it looks like in a flowy fabric, because that can make a big difference. So imagine if your pyjamas were made out of the same material that your jeans were made of, that would not be a great experience.

Matthew: I wonder though, if I would love to see developer educational materials that take that approach, but I think the analogy might be if you had someone make a dress who'd seen it maybe once in a picture and then just went ahead and tried to build it, sorry, make it from memory, because certainly I'm not the world's greatest developer, but one of my great failings is that I'll read the bare minimum I can and then just try and then go back to the documentation hours later and realise that I should have just read it and myself. Yeah,

Erin: Well, that's the advantage that the world of electrons has because once I cut that fabric, it is cut. There is no uncut the fabric, but I can definitely blow away that folder and clone the get repo, and it's like it never happened. So I think that when you think about the irreversibility of something, it really drives your behaviour a lot more careful. The same with cooking. Once you put those onions in that pan, if you have the temperature wrong and you burn them, you need another onion.

You can't just revert on your pen full of onions. I think though that it is somehow we've managed to make people feel that the documentation is their adversary and not their friend. The documentation should be your friend. If you think about hanging out with the documentation and maybe working on something together with the documentation instead of having the documentation be some kind of stern teacher that you have to go to when you can't do something yourself, that it's the wrong frame.

And I think we also don't teach people how to interact with documentation. So I think people feel like, oh, if I haven't read all of the documentation word by word, I haven't read the documentation, but documentation is actually built or at least much good documentation is built for Skimm ability. Just read all the headers. There's plenty of stuff in documentation I ignore because it doesn't apply to me. If you've got documentation about 50 use cases, and I'm only interested in two, I read a lot about API stuff, and you know what? I just don't really care about tokens. I'm sorry, I just don't. So I skip all that part. Also, I'm really mad that JWT is not pronounced jute. I feel like it ought to be. There are analogues in English where words that have a middle W have an oo sound, anyway, sorry, tangent.

Matthew: And you make rope from jute, is that right? So there could be, I think it should be strenuous analogies there.

Carmen: I've definitely had that with lots of abbreviations.

Erin: Yeah. So you skin the documentation, if it's well organised, you'll know what parts apply to you, and often read the troubleshooting section first. That's going to be the part that saves you the most time because it will help you recognise problems at the first stage of encountering them. Kind of like if someone's giving you directions to a place and they say, oh, watch out. There's usually a lot of traffic at this particular spot, or, oh, that sign blew down, then you pay a little bit more attention. If you read the troubleshooting part first, you'd be like, oh, that's how it could go wrong. And also that tends to be the most entertaining part of a lot of documentation, like the car crash part of the documentation.

Carmen: I wonder if there's also that human frustration that into writing that documentation that kind of comes through as you read it. You know what I mean?

Erin: It's like that joke that if you can't be a good example, at least be a terrible warning.

Carmen: And funnily enough, this is something that Kathy also addresses in the book, which really stood out to me, which is what's much, much worse than a bad user manual is making the user think the manual works just fine for everyone else. Which kind of ties into that whole concept of just like you want to make a user feel awesome. You also don't want to make them feel you conversely don't want to make 'em feel awesome.

Erin: Yeah. You don't want to gaslight your users into thinking that everything's working fine and it's them problem.

And I think that everybody's been guilty of that. I have absolutely been guilty of that. When something has a bug and you're like, well, it's almost fixed. It's almost fixed. It's almost fixed. Instead of being just like, this is a bug. We're working on it. Right. I'm pretty sure there's something, at least two things in the word, API right now that I should go flack as bugs because they are not working as intended at the moment, but there's only so many hours in the day.

Carmen: One thing the book addresses is this idea of viewing the world in a high resolution because expertise helps us understand and see more. And I'm curious, in your experience, how does that apply in your experience to developer products?

Erin: I think seeing the world in high resolution, I love that idea and I feel like I get that a lot when I know the vocabulary for something or I know the shape something should take. I think everyone has had the experience of learning that the little piece of plastic at the end of a shoelace is called an alet, and then every time you see it, you're like, oh, I know what that is. Right?

And when you know that you don't unknow it, and then it also gives you a better way, a more efficient way of describing your environment and where you are, how things work in the world. I think the converse of that is knowing at what level of specificity you need to talk to people about things. So if I were telling somebody how to tie their shoes, I don't really need to mention the outlet at all. It's there. It's cool.

I would be very tempted to tell people about it, but is that actually going to help them towards the journey of being able to tie their shoes? No. So there's that thing called the curse of knowledge where so much that you don't know what other people don't know. Then I also think there's the cool curse of cool knowledge where so much cool stuff about a subject that you just drown people in cool things and they don't actually see what they're actually supposed to be for Q on.

Matthew: But I think the curse of knowledge is the fundamental reason why we have Dev Rel because you as a Dev Rel person are the interface that overcomes the curse of knowledge of the engineering team or whoever else,

Matthew: Bridge to the other people who need to get the knowledge to use the product.

Erin: Yes. I also joke that my DevRelsuperpower is being a fairly mediocre developer because I feel like really hardcore, really great intuitive developers if they exist, even they don't notice the problems because they're so good at getting around them, they have muscle memory of getting around them in the same way that really good bakers kind of automatically compensate for yeast that's not yeasty enough. Or, oh, maybe these eggs aren't as fresh. They just naturally adjust. I do not.

I run full tilt into that wall and I bounce off with a bunch of bruises, and I'm like, how do we remove this wall for other people? Whereas really the people who are not, say mediocre developers just kind of ambled around the wall, they might not have even noticed the wall.

Carmen: This is something that really resonates deeply with me because it's something I brought into my most recent position where I embraced the whole, my knowledge of web assembly is really lacking. I'm here to, so to speak, learn in public, and at the same time combat that curse of knowledge.

Erin: And I think asking why ask all the time until people are sick of it. Why did you do it that way? Because sometimes you don't know whether it's something that you have to do or whether it's like a habit. And it can be very tricky to figure out whether something is still needed or whether it's kind of like a developer ritual where people are just doing things because they've always done 'em that way,

Carmen: And it's questioning those norms that push things forward in the first place.

Erin: And sometimes you're going to end up with a broken pile of soggy code, and then you'll be like, oh, I guess that was a load bearing thing. Maybe that was important.

Carmen: Totally.

Erin: But you won't know until you try and it's only electrons. So just wipe the directory. Start over.

Matthew: I feel as though the message of this book is internalised by a lot of people building products, but almost to the point where Kathy Sierra's name isn't one that I hear as much as I used to. And there are reasons for that which we can go into. But what are the other highlights, I guess, of books that you've read or talks you've seen that delve into a similar territory? Because it's not often that people really cut through with a message as clear as this, which in hindsight seems kind of like, well, we always do that, and then you remember. Actually, no, we really didn't.

Erin: That's a good question. I'm not sure what's coming to mind because I think one of the downside of being such a great communicator is that often as Kathy Sierra is, is that people often just straight up internalise this and think of it as a natural fact of the universe

Erin: That gas always been there. And they don't necessarily give credit to the person who introduced them to it because they're like, oh, wait, this is so obvious. But it wasn't obvious until Kathy Sierra made it obvious. And I think a lot of people don't know that Kathy Sierra was also behind the headfirst design patterns book, and unfortunately we don't hear much from Kathy Sierra anymore because she got hounded off the internet by death threats, threats against her family. And I think that that also makes this book and Kathy Sierra really relevant to DevRel because if we do not, if keep hold and maintain safe and welcoming communities, we don't just lose acknowledged experts like Kathy Sierra, we lose the people who could be the next Kathy Sierras, because who's going to take a look at that and be like, yes, that's what I'm signing up for, and who knows how many people we've lost just because it looks unsafe? I mean, I think it's a tragedy.

Matthew: Yeah. Yeah. And I think it's something we don't talk about enough in DevRel is the fact that you are by the nature of the job and extremely public within a niche person. So I always think back to, I think it was Dave Weiner who invented RSS, who said, in the future, everyone will be famous for 15 people, but you are really public within a niche. But that can be a lot of exposure, and I think it's kind of almost glossed over the fact that this is one of the potential downsides of a career in DevRel.

Erin: And also it affects people from different communities in different ways. If you already have an identity that's marginalised in some way, you are much more likely to be a target, and you're much less likely to get the support you need in many cases, which makes things even worse. I mean, I've been pretty lucky so far, and I think a lot of the people I know who've been pretty lucky, but it really is luck that determines a lot of your experience in Dere.

Carmen: I really appreciate you both bringing this up because it's something that I hadn't heard about before reading this book and leading up to this recording, and it was something that really struck me as a silent shout that I missed that really reinvigorates that need we have in our dev communities and tech communities and communities in general to prioritise minimising harm for those that are most vulnerable because we have effects like this. And thank you both for pointing this out.

Erin: And I also think that one of the strengths of the book Badass is it's incredibly clear delivery, and I think I mentioned before that it takes a lot of work to make something clear. It takes a lot of work to make something simple, and sometimes people confuse the simplicity of presentation with the simplicity of the presenter, right? Oh, this is so easy to read. It must not have taken very much work. No, the complete opposite is actually the case.

And so the people who take the time to make things easy to understand are often not given the same kudos as the people who artificially complicate things because, oh, that's complicated. It must be difficult. Whoa, they must be so smart. So I would just ask people to take a step back and think, okay, is this actually difficult or is it just complicated? Those are two different things, right? And to think about, okay, try to understand the effort underneath making something simple versus the apparent effort of the complicated thing that, and read the troubleshooting part first.

Carmen: I love that. I love that. And I think that's, sorry.

Erin: Oh, another thing I like to think about when I read the troubleshooting part first, just read it. If you're trying to evaluate a new piece of technology and you read the troubleshooting part, first think, are these the problems I want to have? Because every technology has problems. Everything in the world has problems, and you just choose the problems you want to have. What are your deal breakers? If you have to use another piece of technology and the troubleshooting section says, well, these two things do not play nicely together, right? That's a pretty easy place to say, oh, nope, this is not a problem I want to have. Yeah, everything's about choices. It's such a shame. Be nice if nothing needed a choice. Anyway, thank you all so much for letting me on to rant about how much I love this book.

Carmen: No, thank you so much. Thank you, Erin. This was absolutely wonderful.

Erin: It's always a pleasure to talk with you all. Just fun to rant about this kind of stuff.

Matthew: So Erin, where can people find more about you, about Wordnik, and about the things that you want to share with the world?

Erin: I'm on Twitter still. We'll see what happens. I'm just eke on Twitter and Wordnik is word NI k.com, like Wordnik, like beatnik or Sputnik. And yeah, I'm pretty easily findable on the internet. If you find that Aaron McKean, who's a professor of neurosurgery, that's not me. Sorry. Very disappointing. I am not also a professor of neurosurgery in my spare time,

Matthew: There's plenty that you are doing in your spare time already.

Erin: I have no desire to add neurosurgery to that list. That other Erin mc key, she can have that domain. I'm really happy for.

Carmen: Thank you. Have a great day. Same to you. Thank you.