Support for the Greater Than Code podcast comes from O'Reilly Fluent and Velocity conferences, coming to San Jose, California, June 11-14. From ops to apps, Velocity and Fluent will deliver the most comprehensive programs ever, including accessibility and progressive enhancement, as well as performance and operability. Best Price ends March 30! Save up to $839 using code GTC20. Learn more at http://oreil.ly/2o07Ufw.

JAMEY: Hello everyone and welcome to episode 72 of Greater Than Code. I'm Jamey Hampton. And I'm here today with my friend and co-panelist, Sam Livingston-Gray.

SAM: Hello, hello. And our guest today is Kerri Miller. Kerri is a Software Developer and Team Lead based in the Pacific Northwest. She's worked at enterprise companies, international ad agencies, boutique consultancies, startups, and mentors and teaches students. She's currently a Builder at Travis CI and also works for Ruby Together on RubyGems.org and Bundler. While all that is factually true, it doesn't actually describe an actual person. Kerri has an insatiable curiosity, having worked as a lighting designer, marionette puppeteer, sous chef, and farmhand, she attended college to study performance production, was once a semi-professional poker player, has strong opinions about keycaps, knows yoyo tricks and enjoys melting hot glass with a blowtorch to create beads, canes and [inaudible]. She's currently organizing and preparing for a four-month tour of North America on her motorcycle which you can follow at motozor.com. Asked to describe herself in two words, she thought a bit and replied, "Lackwit gadabout." So hey Kerri, welcome to the show.

KERRI: Thank you very much. Glad to be here.

JAMEY: So glad to have you. So we like to, often, in fact always, start our shows by asking our guests our signature question which is what is your superpower and how did you acquire it?

SAM: And you can't cheat and say writing awesome bios.

KERRI: I think that my superpower especially lately has been saying. "Hey team, how hard would it be to...and then work for other people, to extend problems and to spin out the scenarios around what we're doing, what are we trying to do, and what are some cool things that we will be able to do in the future with that? 

JAMEY: Can you give like an example? I'm trying to get my head around exactly what this is, like how this superpower works.

KERRI: I don't think it's that super of a power but, "Hey, wouldn't it be cool if..." One of the things that I do that I didn't mention in the bio because I ran out of space is that I do a lot of conference organizing. I'm an organizer for Open Source & Feelings here in Seattle, as well as moonconf which is a conference for functional programming at least once, we're into our second one soon. But one of the things that we do on these meetings, we're all frantically working towards the goal of getting the conference just to happen and Kerri's in the corner at the end of the meeting saying, "Hey, maybe we should have ice cream." "Hey, wouldn't it be cool if we let people make their own stickers?" "What if people could 3D print things at the conference?" "What if you could print your own badges? That would be cool." And before we know it, like now, we've spun out in about 20-30 hours of work for the project. But what do we do to make it cooler in the end, it's seamless possibilities and trying to make those connections. And I think that comes out of my background in Liberal Arts and the Arts and trying to see those connections between disparate things to sort of see how other things could come into what we're trying to do in this moment with the story of that project or a piece of technology that we're using saying, "How can we apply this differently? What other things could we bring in to influence what we do with it?"

JAMEY: So what I'm hearing is that you are a professional good idea haver. 

KERRI: Well, I don't know if they are all good ideas. There's lots of ideas [crosstalk].

JAMEY: A professional idea haver. 

SAM: I don't know. I heard something in there about making [inaudible] for other people and I'm like, "Do you use this for good or evil?" 

KERRI: It's really easy when you're working on a project to get focused on the bullet points of your deliverable, to say like, "Okay, I need to go use this service that it's going to do XYZ." And at the beginning of a project, you often have the context for how the thing, the feature, or the service or whatever it is you're building, how does it fit into a larger picture of how people are working day to day or how they're interacting with your product or your company? By the time you start actually getting down to the ground and doing the work, even in that phrase "down to the ground", sort of like your eyes are down, you're focused on what's right front of you. And in the Motozor community, we talk about this idea of object fixation and you don't look at the ground in front of you because you're going to hit that. You have to look up. You have to look up out two seconds, four seconds, 12 seconds and this is mnemonic for visual...watching for dangers on that road. And if you get focused on what's right in front of you, you lose the ability to make plans for what's going to happen into the future. And when we're working on a feature or a product, we get focused on what are urgent learnables, what do I have, the [kanban] cards, or tickets or issues, or whatever your process is. What do I have to deliver by Friday to make someone happy and get a paycheck? We can really lose that bigger picture. Why are we building this thing in the first place? What problems is this going to solve for users or customers, or other people in the company?

I think my superpower is having the ability to always look up ahead towards that horizon and see what are the next steps? We're going to do this thing. We got a week to get that live. We're going to deliver that. That's fine. What do we do next month? How does this fit in? What possibilities will this open for us in the future to make ourselves and our users more awesome?

JAMEY: It didn't occur to me for some reason that I was going to get a bunch of tips on motorcycle riding things episode which it should have because I know Kerri. But I'm setting for my motorcycle license right now. 

KERRI: Excellent. That is a good life choice.

JAMEY: Thank you.

KERRI: I've been riding for 15 years or more, but I only last year actually got my motorcycle license. And I do not recommend that you do it that way.

SAM: Right. 

JAMEY: Well I have never actually ridden a motorcycle. I've ridden a Vespa because that's what I have exactly one time on Thanksgiving and I crashed it.

KERRI: Oh no! You're okay? 

JAMEY: Yeah. I mean, it fell over in like slow motion. I was like, "This is too heavy for me."

KERRI: You didn't crash it. It just took a nap.

JAMEY: It was on the ground and I was also on the ground.

KERRI: Yeah, we say that yes the motorcycle took a nap or alternatively, that you executed perfectly the first step in examining the undercarriage of the motorcycle.

JAMEY: Anyway, I would definitely come to you for tips. 

KERRI: Oh, gladly.

SAM: I've actually been licensed since I think 1998 or so but I only owned a motorcycle for about six months. I just keep paying for the endorsement, in case I use it some day.

JAMEY: This is the Greater Than Code Motorcycle Gang now is what I'm hearing.

KERRI: Nice! I can't wait to see the patches.

JAMEY: Yeah, we're going to have like really cool jackets.

SAM: I can 3D print them.

JAMEY: Yes!

KERRI: Don't apologize for riding a Vespa, by the way. So for those you who don't know, there's a bias against things like mopeds and scooters and things in the motorcycle world and say, "Oh, you got to get a real badge. It's got to be so big and have like bells and whistles." But it's the same physics of how you ride basically a motorized gyroscope of things in two wheels that goes down the road, like your safety concerns and the physics of arriving at. And the experience, like the feeling of riding motorcycles, the very distinctive one that people talk about frequently of being part of the environment. You've got the same thing on a scooter. And quite frankly, you can get the same thing on bicycles, being part of that environment around you. So, don't apologize for it at all. It's a great easy accessible way to get into what is kind of a tricky thing to get into for a lot of people.

JAMEY: Well, I'm excited about it.

SAM: Sometimes I feel like that bias comes from people who have spent a ridiculous amount of money on their motorcycle and want to feel justified to do it.

JAMEY: I feel like every community has a weird gatekeeping though, because we talk about weird gatekeeping in the programming community all the time. And it's very similar in hobbies, I think. I write about comics and there's weird gatekeeping in comics. There's weird gatekeeping everywhere. And I wish there wasn't.

KERRI: Yeah. I notice that with every hobby that I pickup. And it's always different. There's always a different gatekeeper, but they're there. We tie a lot of our identity up into the things that we do. I am a developer. I ride motorcycles. I am something that informs a lot of people on who they are. And especially if you have multiple hobbies or even conflicting hobbies as I do, it can be really interesting to explore different identities or cross-interest identities. 

JAMEY: You have a lot of hobbies and I'm curious what it's like the most bizarre gatekeeping that you've experienced.

KERRI: I think within each little community, it always seems perfectly normal to that community. It's probably hard to imagine. The glass community, for example, the  BG. It's like, "Oh you make beads. Oh wow!" Like those are the best quotes of the glass community. 

SAM: You don't need a furnace, you just have a blowtorch, kind of a thing.

KERRI: Exactly, like, "Oh, you don't have like a whole team of people to blow pipes and everything." Or, "Oh you work in borosilicate glass. Clearly, you only make drug paraphernalia with your special glassblowing techniques." But that's the story. That's like the human way that our brains work around metaphors and illusions and categories. And we apply labels and say, "Oh, this person works in this sort of style," so that means certain things about them. Maybe that's true but more often, it's not, quite frankly. 

In the yoyo community, the chart is Throwers. We are Throwers, that's what we call ourselves. There's different kinds of yoyos and these yoyos have different designs and styles, like how the axle works and how the design of the body is, the kind of string that you use. All these sorts of things are tools to enable you to do different kinds of tricks. But when you're doing yoyo routine, you can't quickly change to a different kind of yoyo. And so yoyoers or throwers will almost specialize into one sort of style of trick because you're using this one kind of yoyo that enables that kind of trick. And so, you can't mix and match as easily. You can't cross over. And so you get this little tiny [inaudible] subgroups for this kind trickery or that kind of trick, on string, off string. It's all super technical and highly specialized language. But it's the same way where we have people who are a Ruby developer versus being a Rails developer or are you an actual Ruby developer? Do you write Django or do you use Flask? All these sorts of distinctions that inform us as shorthand about the skill set and the toolset and even the work process around somebody, what they do and how they do it.

JAMEY: I also feel like people's response when you tell them what you do is almost shorthand that informs you like if that person is a jerk or not.

SAM: Yeah. 

JAMEY: I think I've told this story before on this show but I was at a party one time and I was like, "Oh, I'm in tech." It was not a tech party, it was a [inaudible] party. And I was like, "Yeah, I work in tech." And he was like, "Oh, what do you do?" I'm like, "I'm a developer. I'm like a full-stack developer." And he was like, "Oh, what do you write in? I'm in tech, too." And I'm like, "Oh, I write in Rails." And he goes, "Ohhhh, so not a real programmer." And I was like, "What?" And he was like, "Well, Ruby is the scripting language." And I'm like, "You don't even know..." I was so shocked that someone would come up to my face and say something to my face that I would see on Twitter that I didn't even know what to do. 

SAM: Right. That's not even a legitimate categorization of the language anymore.

JAMEY: I know. I was like, "Where's your anime profile picture? I can't see it." 

SAM: Yeah.

KERRI: It's interesting to be in the Ruby community and the social community as well that [inaudible] myself with, like that's so abnormal, like we're not part necessarily of contempt culture in that hard core world. There's still contempt, like we're deprogramming ourselves and like unwinding years of that but it's much more welcoming in circles that I'm in. When I go to other communities, they still have a stronger tradition of that. I've been attending and speaking to a lot of conferences that are polyglot or not the traditional Ruby community that I'm normally a part of and finding [inaudible]. It's interesting to compare and contrast what I like and what I dislike about my community. I learned a lot by going out away from these comfort zones. It's kind of like travel but technology-wise.

JAMEY: Emotional travel. 

SAM: Cultural exchange.

KERRI: That's why I'm not worried about the "Is Ruby dead?" thing that's been going through most of the Ruby communities the last couple of years because whether or not Ruby is dead is not really an interesting question per se, but the idea of like, well if the argument is that we have all these Ruby developers that are leaving Ruby. It's like that's okay. They'll go and they'll take the awesomeness of this community and bring it to other languages and like set up like their own, like seeding the good parts hopefully out to other languages and influencing not just communities but also the languages themselves. I see a lot of languages will trumpet themselves or where the bullet point is, it's as easy as Ruby or Python. It's like, what impact that these languages have had, like bring a certain...based on that perspective of developer happiness, making things easy and being nice to people and bring that outwards into the technology itself.

SAM: Yeah. I was actually at the Portland Ruby meetup last night and Lee Baillie gave a really excellent talk about Rust from a Rubyist perspective, and it was the funniest presentation I've ever seen. They said they spent like two weeks of 12-hour days just drawing cartoons for this thing. It was very much in the style of why the lucky stiff. 

KERRI: Oh, I'm so sorry I missed it. 

SAM: It was fantastic. They said they gave it at Rust Conf 2016, so there may be a video out there on the internet as well. But yeah, totally worthwhile. And yeah, totally what you're talking about, if like taking Ruby awesomeness and making it part of that diaspora.

JAMEY: I totally agree. I think that the reason that communities can get insular sometimes is because it's easy to be like, "Well, everyone in this community understands what I do and [they respect] that." And it can be intimidating. It's like step out of that community into a place where someone could tell you you're not a real developer. And hopefully, that won't happen to you but it could. And so I think that people insulate themselves because of that. I can't really blame people necessarily but I really like this idea of taking it out to different parts of the community at large and spreading like, "This is how we respect each other. And now you've seen what I do and you know me and you can respect me for what I do. And now, you do respect other people that do the same thing as me for what they do." Does that makes sense?

KERRI: Yeah. There's something wonderful about travel and that you learn that everybody is the same. So right now in North America, it's winter time and the motorcycle community is pretty much shut down because you don't want to ride in snow. Nobody wants to do to that. So a lot of people are traveling down to Mexico and mostly white affluent North American community. There's a lot of biases about that especially in a lot of the women riders' groups that I'm part of - will it be safe to ride in Mexico, because all we hear in the news all the time is the story of violence and gangs and whatnot. But when you get there, they're just living their lives and getting their kids to school and having lunch and taking a coffee break and putting gas. All of those concerns in a modern world are there. And even in more rural places, it's still the same. We're taking care of the farm or we're running the store or the shop or whatever it is. It's the same human concerns of living in a society. It's not that different. There's differences and those differences are really interesting and fascinating. Those are usually culture but the mechanics of how you move through your days are so much the same and I don't know, there's something really human about that, that's really wonderful.

And I get the same thing when I go to a PHP Conference or a Go Conference, where the problems the people are solving are almost always aligned and they're almost always the same kinds of problems. I need this server to talk to a server. I have to take this string of characters and transform it into this other string, or I need to aggregate some numbers from this [database]. We're solving those problems in different ways but often those differences are less than similarities.

SAM: So it sounds like maybe the stories that people are telling themselves about what it's going to be like to visit another country or go to a conference from a different programming culture, may be at odds with what the actual reality would be if you tried it.

KERRI: Yeah, I think so. I think that the stories that we tell ourselves, they're useful. Most stories are useful. It's useful shorthand for how we work. And a lot of people talk about this when you start looking at how we bias ourselves.

I would recommend a great talk by Sam Livingston-Gray on human biases. It's a wonderful talk, it really is. I revisit it often. But all of those come around because of the central flaw in the human wetware that we categorize and we label things as abstract concepts so that we can handle them, so we can easily categorize 'this is dangerous, that is not dangerous. I could eat this, I can't eat that. I will defend this person, I will not defend that person'. There's a lot of the base psychology on that. And that even extends up to the stories that we tell ourselves about what different technology is used for, what it's good at, what people in those communities are like and who we are as well. That can be a benefit, but it's also a hindrance because it gives us a context for understanding ourselves. And it's when we can we can break out and challenge those constraints of what the story tells us, we can tell a new story and then we can begin to tell stories about those stories.

SAM: Hey, we have a surprise bonus panelist today. Christina Morillo has just joined us as well. Welcome.

CHRISTINA: Hi. Happy to be here.

JAMEY: Glad you could hop on. 

CHRISTINA: Me too. So, what are we talking about?

KERRI: I think right now, we're kind of edging into talking about storytelling and contextual framing.

CHRISTINA: Ohhhh, I need to get better at storytelling. Yes, I want to learn all the things about storytelling.

KERRI: I think that storytelling or to tell a good story should be something that we hire for.

SAM: I agree with you even though I don't have that skill and I wouldn't get hired for it.

CHRISTINA: I know. 

KERRI: Well, that's what I was going to say is that in SICP, Structures of...

SAM: Structure and Interpretation of Computer Programs.

KERRI: Yes, thank you. The author of that, one quote that I got out of that entire book was this idea that software is written primarily [inaudible] by humans and it's only incidentally run by computers.

SAM: Yeah.

KERRI: And some good code tells a story. It tells a story. And that's what I love about the flexibility and eloquence of Ruby in that it allows us to tell stories. When I go to some other languages that are a little more precise, they're a little more computer-y, if you will. 

SAM: Constrained.

KERRI: Perhaps. They don't express things quite as well. One metric I use...whenever I start a new company or a new project, people always apologize for their code. Like, "Oh, I'm so sorry, such a mess." Well, that tells me part of the story about what went into building this and what your experience has been around this product. But one of the metrics I use to see if is the code actually good or bad is can I read it out loud. If I can actually read code out loud and in Ruby it's actually fairly easy, right? If I can read it out loud it's kind of close to English and it's kind of telling me a story, I know that anyone who could read English and comprehend it well will be able to abstractly understand what mechanical things a piece of code is doing. And this is why compositional code is very interesting where we extract sub-transformations and some procedures out into methods with good names [inaudible] is important to allow us to tell that story and let us engage the language centers of our brain to really internalize what something is doing rather than trying to hold [inaudible] computer and hold multiple variables and transformations in our head. We can understand it with using language and leveraging that labeling structures that already exist in our human brains. 

CHRISTINA: What was the name of the book?

SAM: It's the Structure and Interpretation of Computer Programs. The first edition was written in Lisp and it was used to teach an intro to computer science class at MIT for many, many years. My understanding is that MIT has now switched that class over to use Python.

CHRISTINA: Okay.

KERRI: That surprised me. 

CHRISTINA: Thank you. Also, that's interesting that they would switch over to Python.

SAM: I had a copy of SICP for many years that was given to me by somebody who had had it for many years and never read it and then passed it on to me. And then I kept it for many years and never read it and passed it on to somebody else. But I feel smarter for having owned it, right?

KERRI: It's one of those books. It's like this Design Pattern book. I'm like, "I'm never going to read it," but it's there.

JAMEY: When I was taking Calc 3, I took Calc 3 when I was in 11th grade and that was a lot. And I was so frustrated. I remember sleeping with my Calc book under my pillow and I'm like, "Maybe I'll dream about Calc and learn something." I mean, I did pass the class. I don't remember anything about Calc. I'm very bad at math these days. But I feel like it's one of those stories that you see in like a sitcom. I'm like, "I really did that in my real life." 

SAM: It's interesting that you mentioned Calculus though and learning Calculus because I got super lucky. I went back to get a Computer Science degree which for some reason required me to learn Calculus, I don't know why. It was to go with the Physics that I also don't use. But as I was taking the first Calculus course that was required, I coincidentally was also reading Neal Stephenson's The System of the World. And as it happens, Newton and Leibniz were both characters in this book and they were talking about what they were using Calculus for. And so, studying a little bit of physics and reading this book and learning Calculus all at the same time, the book helped give me a narrative and a story to fit Calculus in too. So even though I don't understand it or I don't retain any of the mechanics of like how you integrate or otherwise work with Calculus stuff, like I've forgotten the terminology even. But even though I don't use the mechanics, I understand what Calculus was for and why it was invented. And it really changed the way that I look at the world and still does.th

JAMEY: That's really cool. I'm glad to hear that I'm not the only personal that didn't retain anything out of Calculus.

SAM: Skills are use it or lose it.

CHRISTINA: Yeah, I didn't retain anything either. I still don't understand what it's really used for, but okay.

KERRI: The story that we tell about math is an influential one. I barely escaped through 9th grade Algebra. After really actually being a mathematician, I was like after school, at STEM programs and math and everything. Pre-algebra was fine. Algebra 1, I kind of struggled with. And then, 10th grade, we got to Geometry and I bombed out of that class. The third quarter of sophomore year, even if I aced everything else and there's no way I was getting out of that class with a passing grade, I said, "Oh, I guess I'm one of those people that just doesn't get math. I'm going to go follow the [inaudible] path." So I went into performance production. I ended up at college for performance production, doing design work, laying design, things like that. It was years later, I dropped out of college to get into tech which was a great decision for me. I went back though to do a couple semesters in performance production program here in Seattle to kind of like finish up my degree work and quickly realized during one class when we were building sets that somebody happened to mention and happens [inaudible] to figure out this angle of a support beam or something. I was like, "Well, tell me more about that." Got me to find out, I knew Trigonometry and I'd be using it for years building sets and designing things and understanding load bearings and how the load shifts over time as you shift these different support triangle trusses and things. And so, suddenly the story has shifted. It has shifted from what I was being taught by one particular teacher in one particular year of my life whether or not I was good then to this is something that I can use and it has value and I already know it and it's not scary at all, it's not intimidating. It shouldn't be. It was just human knowledge and I'm a human and I have a human brain. So then the story about that shifted. The story around Trigonometry shifted from here's the thing that really smart people take when they're preparing to go to Harvard or MIT to here's something from a woman in a [inaudible] construction shop in an old warehouse is using to build something. When that story shifted, it really made the difference for me. The same thing happened to me in tech as well. My tech story in a lot of ways involves shifting that story from I just hack on a little Perl and PHP to I write code, I'm an engineer.

One of the things I'm proudest of in my career is helping to start Ada Developers Academy here in Seattle. I was one of the [inaudible] teachers of [inaudible]. It's a great program, if you don't know about it. You can look it up later.

SAM: Yes. Ada is amazing.

KERRI: Oh, I'm such a fan. I'm such a fan of it and I wish I could be more involved. But I was a teacher of the [inaudible]. There was a transformational moment in the six month classroom. Around somewhere between 6 to 10 weeks where women in the program are changing their story from I'm learning code to I'm writing code to I am an engineer. It was changing that self-definition from this is something I am learning, this is something I am or this is something that I know and something [inaudible]. And that was a transformational moment for them where it empowered them and expanded that. And it gave them these new superpowers once they changed that story about their relationship to a thing they were interested in.

CHRISTINA: So do you feel that shifting...I think I know the answer to this. With education and learning, shifting the story or the context will allow people to become more receptive to learning. Like you have to learn this because this is going to get you into Harvard versus this is what this little old woman in a shoe uses to support her family. I think I know the answer to that, but I would love to hear your perspective.

KERRI: I think I agree. That's the joy and wonder that I found when I first approached Ruby was that I discovered why the lucky stiff's Why's Poignant Guide to Ruby. And up in that point like yes, we were talking about SICP earlier, this 900-page hardbound books with five authors and they were printed by academic presses. That was a computer textbook. The other ones you had were Learn C in 5 Hours or The Internet in 24 hours dummies books. There was a different kind of approach. Why this book completely changed the perspective from here is the thing that you need to study in this academic rigorous way to here's this thing that is fun and weird and a little wacky and whimsical. And it was very practical and it talked about code in a way that was experiential and contain metaphors and allusions.

Ones that I really remember is in Ruby, you put an @ symbol at the beginning of the name of a variable and that makes it an instance variable. And if I'm remembering correctly, why describe that as, "It's like a little whirlpool. The value that's in that variable falls down the whirlpool and is spread out all over the object." And I was like, "That's really weird. I love that. That's great." 

I think the other one was you have an ary.each do and then you have a pair of pipes and a temporary variable name for the loop over that array. And as he described it, it's like all of the values in the array are on a playground slide. And one by one, they walk on top of the slide and the slide down through the loop. You can't see because I'm not on video, I'm doing hand gestures. But just thinking about this piece of code as a bunch of kids in a playground that would have to slide. I'm like, "Oh, okay. I understand that, that's easy." It's great because I had the story to attach it to in this thing. Is it a perfect metaphor? No. Is it maybe 60% accurate? I don't know. I don't know what the actual number is. But for me, that just it opened up and it made it instantly relatable. When I see that structure, that's all I think about even today. Ah, it's a bunch of numbers that are just taking turns on a playground slide.

SAM: I never actually read that book much as a programming guy. I've mostly approached it as a work of art but that's really fantastic.

KERRI: There was also the book that made me...[inaudible] Ruby. But it was the one that said that the Ruby community is full of heroes and there is a space for whimsy here. And that's what I responded to. And I still try to do that with a lot of weird...I do weird gems and weird projects all the time because I try to keep that spirit of exploration, keeping it fun and interesting. Because I don't know what weird thing I've done is going to inspire somebody else but I hope that somebody responds to something I do. I just assume that there's someone out there who has heard something I said or worked on. 

JAMEY: And did something even weirder hopefully.

KERRI: Yes. I've had the opportunity to work with the students that I taught at Ada and they're all amazing. They've taught me things now. They've been out like a few years in the industry, several years now at this point and coming back and working with them, they're teaching me about code now. I love that. I love that (a) that I don't know everything which is amazing and awesome because there's always something new that I get to learn, not just because technology is moving fast which is a broad topic and that I gave a bunch of other people tools to go learn things, to come back and that leveled me up. 

CHRISTINA: I remember reading something about that like if you want to learn something better, teach it. So, that's how you retain versus just getting it kind of forwarded into you like you show it to someone else.

JAMEY: That makes sense to me because like I find that I know enough about something to do it, but I don't know enough about how it works to teach it. So I'm like, "Oh, I can do this. I can show someone how to do this." And then when I go to do it, I'm like, "Oh, my gosh, I have to learn more about this in order to do this," which is cool.

CHRISTINA: Yeah.

KERRI: That was actually my college experience. I tried Goddard College which is a John Dewey school. And so, it's democratic education. I should get that right because I'm an alumni. It's this idea of like one approach to education is you sit in a desk [inaudible] and they pour information out on you and you will absorb 75% of that, and every day, [inaudible] what the teacher says. My school and schools like it are around this idea of democratic/socratic inquiry. And so, it's small groups organizing around topics to learn and discuss and share and inform each other.

So for example, I took a class in Medieval History. That is a class that is right for lectures. The second [inaudible] the way that we did it was we did field trips to look at Medieval art exhibits and discuss the art and teach each other. Each person would get an artist and they learned about that artist and wrote a paper about it, but then we would comment and have discussions like active discussions around the art. Or one person would learn about...we would focus on reading books about one side of a conflict and somebody else would read books around the other side of that conflict. And then we would debate and discuss and educate each other about the opposite of what we knew. So, learning things through the exploration, through the doing of things, through being actively involved is an amazing way to learn and it's not suited for everybody but it's a valuable way of approaching it.

SAM: I feel like this comes back to storytelling too though because Christina, what you were saying about how you really have to teach something in order to learn it, I feel like there is this process that happens when you realize you're going to have to help somebody else learn a thing. You start thinking about what order did they need to learn these things in and how you're going to tell that story and doing that forces you to organize the information in a new way in your own brain so that you're capable of telling that story.

CHRISTINA: Yeah, I usually incorporate a lot of analogies. So, my husband is not in tech. And so when I'm trying to explain things to him...he likes basketball, like a huge fan and he plays. So I have to break it down to him in basketball terms. I'm just like, "You know when you're at the free throw line..." It's really weird but it just works so that I can like break down these concepts. It's what works. But I find that analogy has helped me a lot which is interesting because I noticed that a lot of these code schools, they don't take that approach and I've always felt that it's like a missed opportunity. A friend of mine was an instructor and I would say, "Why do you teach like Day 1: Hello World?" I'm like, "Why don't you show the person like, you know how you guys go on Amazon.com and you add something to cart. This is what's happening." Let me show you how that works in the backend as opposed to this weird interface and then you just start typing all these weird characters. That's how a newbie would see it. I feel like they should relate it back to something that the person uses every day so that it can make sense but that's not the case.

JAMEY: I had a very similar experience when I was studying computer science where my first intro class, we were learning Java and we learned getters and setters and it was kind of just like, "Here is what a getter and a setter looks like." You're like, "Public void, that's just what you write." And I didn't understand why, "Just memorize it. These are what you write." I'm like, "Okay, I memorized it. Now I can write getters and setters." And then in my next class the next semester, we talked about like method calls in general and we're like, "Okay, this is what the first word means and here are the options. This is what the second word means and void is that you're not returning anything." And it was suddenly like, I understood this and now the thing I already memorized, I also understood which was actually a pretty cool feeling to go back and be like it was this moment of eureka. Everything I had learned in the past semester suddenly poured into my mind as things that made sense but I kind of wished that I hadn't had to wait so long to get to that moment.

SAM: Yeah, I worry about what happened to the people who dropped out before they hit that eureka moment.

KERRI: There are the people who failed out of 10th grade Geometry and decided they couldn't do it. 

JAMEY: I had a great friend who dropped out of computer science not because of that specifically but he didn't like debugging. And when he realized that, "Oh, this is a thing I'm going to have to do at all times and I'm never going to get to stop. I don't like this. I don't want to do this." I was like, "I can respect that. It's not for everybody." So, he dropped out and then he learned five languages like speaking languages, and he was like learning languages just like computer science except I don't have to debug. And now he's like a translator. He speaks nine languages which is so cool. 

KERRI: So basically, he's looking for errors in communication between two people. It's like debugging all the time. 

JAMEY: He was like, "Why this didn't work?" And it was because there was a semi-colon and I'm like, "Sorry, this is what happens." But he doesn't have to worry about that now.

KERRI: My story similar to that is network communication. People [inaudible] multiple times were like, there's always different levels of layers and there are http packets and trains and [inaudible]. It's like it's incomprehensible. The way that I taught it at Ada was we need a paper airplane and we just turn that paper airplane back and forth like you're the server, you're the database so people can have a physical connection. We're not going to talk about technical things, we're just going to talk about the concept of something [inaudible] system. Posting was like, "Okay, we're going to write down some stuff and put it in an envelope and now you get to pass the envelope around and certain people can open the envelope and look at it." So just try to find different ways of explaining things because you need that empathy to understand like what's the context that somebody brings to the story that I tell? What do they understand and what is interesting or important to them? [Inaudible] introduces itself by things like here's one: NSQ is a real time distributed messaging platform designed to operate at scale handling billions of messages per day. It promotes distributed and decentralized topologies without a single point of failure, enabling fault tolerance and high availability coupled with a reliable message delivery guarantees.

Now, I'm pretty well [inaudible] in these kinds of architectures. So I kind of resent what it does but I still stop and think about it.

SAM: Yeah, that doesn't tell you why.

KERRI: Yeah, it doesn't tell me why. It doesn't tell me what problems are you solving especially when you're working in something that's like a fundamentally different kind of architecture. You have to change your ideas of relationships, how the services work. It's awkward and weird and so often you find tech explains itself like the bullet points of its feature set rather than it's used cases and what your relationship to it should be. That's what I loved about...one of the things that I think contributes to why Rails was so popular, in addition to what you said, [inaudible] was this idea that it was the classic build a blog in 10 minutes.

SAM: Yes.

KERRI: And every variation of that. It's like what do you want to do? I want to build a blog. How do you do that with Rails? [Sound] and it's done versus if you just went through the bullet points of what Rails does and what it is, you lost people. You just lost them because there's no empathy for like, "What problems do you have that I can solve?"

SAM: Yeah. I've heard so many stories about people who they came to Rails because they didn't consider themselves a techie. They wanted to build some business or scratch some itch and they happened to run across Rails and it was accessible enough for them to hack out whatever they actually needed to do. And it let them get far enough to do that.

KERRI: [Inaudible] WordPress. Some ungodly amount of internet runs on Wordpress. And part of contempt culture is we make from WordPress, we make from PHP which we shouldn't do. But that persist. But my goodness, look at all these people that want to get a website for their dog-walking business or their wedding photography or they want to share vacation blogs or whatever it is. The tech didn't get in their way. The tech solved the problem for them. And it does so in a way that is approachable and relatable and approaches people as individuals with problems. I'm going to solve your problems. Here are the problems that you have that I can solve for you rather than being like the feature set. Motorcycles are like this. Motorcycles will advertise themselves based on the torque and the foot pounds, how many horsepower and all that. And I'm just like, "Nah, it's meaningless. It doesn't mean anything."

SAM: Right. And the reason that we get on motorcycles in the first place is because we want to experience that freedom of moving through the world without tons of metal around us.

KERRI: Exactly. In the midst of all of that sort of bragging about the numbers around motorcycles. The number on a motorcycle usually refers to the size of the engine, just a little bit of motorcycle trivia for you, if you don't know. Instead of bragging about how big the engine is...years ago back in the 70's I believe, Honda had an amazingly influential motorcycle ad as a campaign where the tagline was 'You meet the nicest people on a Honda' and had all these pictures of like really nicely, smartly dressed people riding to the farmer's market or brunch or picking flowers, just living their lives and doing this thing. And it was like this solves your problem. It wasn't bragging about how fast it goes. It wasn't bragging about how awesome you are going to look riding it. I was like you have a problem which is getting around your city easily in a carefree way, we're going to solve that.

JAMEY: I have also experienced this. I got a Vespa because I think Vespas are cool. And then people are like, "What number is your Vespa? What year is it?" I'm like, "I don't know." "How can you not know?" "Because I've just got it. I rode it once. I don't know. I could look it up on my papers." It's weird to me that people think that that's the most important thing about it in general.

CHRISTINA: Some people are into features. They figured that that attracts more buyers, I guess.

JAMEY: I'm like, "It's blue. I love it."

KERRI: I think especially once you [inaudible] in a community, it's very easy to become obsessed by the features because that's your frame of reference. I'm working a lot on Sinatra right now. I use Sinatra as a teaching tool but I haven't actually like really used it in production as much as I am right now. And I keep doing that thing where I'm like I'm trying to write Sinatra as if it's a Ruby app. The same way as if people that have come from one language or another, you write that new language in the style of your old one. And you complain because the new things doesn't do what the old thing did. "Why doesn't Sinatra make it easier for me to use active record models? I don't understand. This is horrible. Blah, blah, blah." Because I've lost the wonder of what it's letting me do and I've lost sight of what the problems that it's letting me solve in the way that it's solving these problems. I might be a motorcycle nerd and I'm like I know all of the numbers. Those numbers actually maybe mean something to me. So I'm interested, Jamey, in what your new Vespa is because that's interesting to me. But the thing that we do share though is that very common experience where experiences overlap that diagram. It's that excitement and initial thrill of riding and that pleasure that you get. If I'm going to connect with you about Vespas, that's where I need to aid my communication is in that place, that place of excitement and wonder and magic. I'm assuming that you like it. I'm assuming that it's all magical and rainbows for you. I mean, it will be. It will be awesome.

CHRISTINA: Let's say we were in an environment where they are very feature-set oriented instead of problem solution use case oriented, how do we connect the dots? Like how do we kind of flip it on its head, so to speak, and say let's look at it from a use case problem and let's create a story around that versus you telling me all the features I'm going to get for 1999. You know what I mean? 

KERRI: I did a lot of work in advertising or I worked for advertising agencies in the 90's coming up. And one of the things that they often do well is to make personas. And very often what we would do and I actually did this in a number of start ups when I worked at them in the last 15 years is you think if your three or four personas and then you put unique posters of them. You put them on a wall of like this is what this person likes. This is what they do. This is the part of the country they live in like maps and cutouts from magazines or articles or whatever. We make collages basically of these people and they're hung in prominent places where we're always surrounding ourselves with, like the humanity of our customers. You can look at it from a technical perspective and like we have to keep these people in mind that they serve our needs. But also, there's an emotional component too of how am I communicating with the people around me that serves these people. 

As a lead developer, what are your jobs? I talked earlier about like in motorcycle, you just look out up to 12 seconds ahead and see what's coming at you. As a lead developer, that's part of your job is to not just focus on what's causing this bug and how do we fix it? But how do we do remediation with the users, that's the next [inaudible] and how do we stop this bug from ever happening again? What things contributed to that in our process? How can we educate? We have this ever expanding view of what the territory looks like. You're always trying to bring that up. So I have Post-It notes on my monitor to remind me to ask questions about that bigger story. What's the human impact? What's [inaudible]? What will this let us do in six months? What will it stop us from doing in six months? So I make sure that I ask those questions and kind of keep those in mind.

CHRISTINA: In the financial industry, I worked in the financial industry before. In doing security, so they call that tactical and strategic. I used to find that really funny. I'm like, "What? What are you talking about." They would tell me, what can we do today versus what can we do in six months? Get to that 30000-foot view. I guess it does come in handy.

KERRI: Yeah.

CHRISTINA: I like the way you kind of explained it though. It makes much more sense. You're a good storyteller.

KERRI: Oh, thank you. 

SAM: Total tangent here but that reminds me of the time I learned a really interesting phrase. You talked about tactical and strategic and those are bits of jargon that I understand and sort of have internalized. But the important part is that they are technical jargon. They have specific meaning within a specific context. And I was at work one day and I was talking to somebody and I said, "Wait, what was that phrase that you just said?" And then they repeated it and they said, "Oh, it's a term of art." And I was like, "Okay, what the hell is a term of art?" So I went and I looked it up. And I realized that term of art was a legal term to describe a bit of a phrase or a word that had specific meaning and specific context. So term of art is legal jargon for jargon.

CHRISTINA: Term of art is legal jargon for jargon.

SAM: And that just blew my mind.

KERRI: Excellent.

CHRISTINA: It's a legal jargon for jargon. I love it.

KERRI: Can I tell you a story? 

JAMEY: Please.

SAM: Please.

KERRI: Okay. This kind of reinforces I guess or builds on what I was saying earlier on stories. My Grandmother Miller, she was born in 1917/1918 in the 40's and 50's. She was the postmistress of my small hometown during World War II. She was postmistress and she had been the postmistress for 30 years. Sometime in the 50's, we're a little handwavy about this in my family, one Friday the train that was delivering the new stamps and the payroll, the actual cash that she was going to pay the postal carriers with was late and it was delayed. Came in right as she was closing up shop on Friday, so she didn't have time. They didn't have a safe and she didn't have time to deal with that. So she put it in the coal fired oven in the break room at the post office. Well, it was a 3-day weekend and it was very cold that weekend. So she got it on Tuesday and made herself a pot of tea. She put the kettle on and, "Do I smell something burning?" 

CHRISTINA: Oh, no!

KERRI: Yes, my grandmother set on fire the equivalent of several tens of thousands of dollars in cash and was investigated for about two years by postal inspectors. And that's the story that gets told all the time in my family. It's probably not 100% true. There's those details of them that are fuzz and everything but it tells a truth. And that truth is that time my grandma set money on fire and like forgot that. And that's an entertaining story and I told you a little bit about like my hometown, and who I am and what my family has done historically. All those sorts of things, the context of who I am and where I'm coming from, and some funny information.

If I just told you, "Hey, there's one time my grandmother accidentally set on fire $50,000." End of story. That's the bullet point of the facts that happened. And I think that so often we let facts and data and information be the story, when it's just like here's your datapoints. And we leave it up to the users to contextualize that data. Really what we need to do is we need to be providing context for data and for that information so that we communicate not just what we want but make sure that it gets across the story behind that information, what it assembles into. Picture that needs is understandable by the person who works and communicate with.

[Inaudible] talked a little tiny bit about code being read by humans primarily and only incidentally run by computers. And I think that story healing is not just in code. It is in documentation. It is how we write bugs, it is how we write e-mails to each other, it's how we speak to each other in Slack, it's the emojis that we choose, it is the pronouns, the names that we use for people, the language that we choose to interact with each other. All these combined together to reinforce and tell the story of what's happening and really let us communicate not just datapoints but actually the truth of what we're trying to get at. The capital features, the things underlying it all.

JAMEY: I think there's two parts of a story. And one is what it's telling you and the other is how it makes you feel like almost the aesthetic that surrounds the story. Aesthetic is very important to me and I think about it a lot. And I like your story about your grandmother in that because like what it's telling you is that this is what happens. But I feel like there's a lot of aesthetic surrounding that story that makes me feel a certain way and I think that's what it's trying to get across. I feel like it's kind of well rounded in the sense of like now especially when you said it tells you something about this town and where you grew up. I think that's totally true and I think that's what this small town aesthetics that I'm getting from it. I really liked that. That's a very important part.

CHRISTINA: I'm reading this book. It's an audio book but it's Talk Like TED because that's something that I've actually been focused on like how to become a better storyteller so that I can just become a better communicator all around by telling stories. And so, I'm going through this book and he's talking about that point about that motion element and about that's how you connect or get people to connect with you. And when you get them to feel something, like when Kerri was talking about his grandmother, I vividly imagine this. I imagine like this. I imagine this one woman and the place and the money and the fire and the smoke and the people. I don't know. It just made me feel like, "Oh my God, what happened?" It's like watching a movie. So, I guess it turned on my imagination and that's a big part of what motivates people - the feeling. So I can see with the feature stuff, it's like, "Ugh, feature." Story is like, "Oh! I can meet people if I drive a Honda?" 

KERRI: One of the things that my family frequently does is our family gathers. We just sit around, we tell stories to each other. There's something about it, we just tell the same stories over and over again. One time I went home with a long-term partner, and afterwards they were like, "I can't believe that every single story that you and your family told each other tonight were the same stories I heard about five times already. I don't understand that. I'm really frustrated." I'm like, "You have to understand that when we tell that story, these stories to each other were saying I love you and were saying I care about you." And look at all these other examples in our family's history that we have this history that carries forward that even the mistake of setting on fire all of this money, we remember that fondly and we all laugh. We share in that moment for her which is really stressful, I can imagine. But we've told it and we've knocked off those rough edges and so it's an expression of inclusion. 

And so when I write code or a documentation or a bug, I'm doing the same thing. The effort that I'm putting in to make code clearer or more simple, maybe it doesn't run as fast. Maybe it takes 2% more compute cycles but it's still an expression of care for the next person, of compassion and tenderness and welcoming. It's an invitation to learn something, to look at my code and make it better, to participate in it. I want it to be at that level. I want the story of what I do to be inclusive and expansive.

JAMEY: I love that. My family is also story repeaters, chronic story repeaters. It's like a thing. And I think you've hit like why. If a story was just to learn the facts of the story, you would only ever have to hear it once. But the fact that you want to hear the story more than once or you'll see a movie more than once, you read a book more than once, it's because there's more to it than just like a list of facts that you learned that are in your brain now. My family is actually such bad chronic story repeaters that we threatened at one point to like number all of our stories so we could just be like, "Oh, story number 67." Everyone laughs, we don't have to tell it which obviously we didn't do because that defeats the purpose. But I remember once I was dating someone new and he told me a story that he had already told me and I was so happy. I was like, "He just repeated a story to me. He's going to fit in so good in our family."  

KERRI: Stories change over time too. You'd be each repeatedly telling, you just make it more entertaining but still closer to like what is the truth that I'm sharing here. That's why I love hearing stories evolve and change over time as they get retold through partners. I told a story about something that they and I have done and they turned to me and said. "That's how that happened. That's not true." And I'm like, "No, but it is if you think about it."

JAMEY: I love hearing the same story told by two different people.

KERRI: Yes.

JAMEY: The best.

CHRISTINA: So what are the most important parts of the story especially as it relates to code like when you're writing code and you're crafting a story around that, what would you want the next person to take away from it? Like what are the elements that make it a powerful story?

KERRI: In actual storytelling, storytelling is a skill and it's an art that you taught. And people do teach it. There are storytelling workshops and things like that. I've attended a few of these and one of the consistent pieces of advice in storytelling is you should know what your last line is going to be. I think that that pertains a bit to code as well. A lot of product development processes talk about when to press release for your feature or your product, when to press release first? Like how would you announce the thing that you want to build? How do you tell that story? And that can become part of that theme of development for building features and the attitude that you take towards delivering that in a similar but not...maybe a little tangential.

But I recently remembered Sandy Metz's great talk on testing some years ago which talks about testing interfaces, inputs and outputs only. You don't test the implementation, what happens inside of the code. You test what comes in and what goes out. And similarly, that's the way that I want codes to be. I want people to be able to see where something starts and they can write it down if they need to, but it can get a little fuzzy. But I'm going to try to hide that as much as possible and focus on the output like where is this going? What's the ultimate goal? Because so often in code, especially, it's really easy to have a multiple branching paths to your code and we're using exceptions, control flow, like what happens if this [php call] breaks and [inaudible] this whole other thing. You're never cutting it back to [inaudible] like what the heck was I even doing.

I find this with code that does a lot of redirection and a lot of delegation where I can't understand. I'm six models deep and I have no idea who's talking what. So I've done a lot of work around [inaudible] relationship diagrams and [inaudible] to try to get my own brain around very complex legacy systems to understand the flow. If I don't understand the story of how something [inaudible], I need to be able to get my hands on it somehow. So when I write code, I really want to focus on making it approachable from that beginning point where people can see at a top level what is [inaudible] of this code, where does it start, and where does it end, where does it come back out. All codes are some sort of transformation. We take a piece of data, we transform it or we react to it or we transform it somehow and we respond backwards. It's kind of a classic three-act structure, like we have an introduction, we have a rising act...what is the five act structure in Shakespeare? We have the introduction of all of our players, all the characters are introduced and we have rising action and we have conflict, and denouement and conclusion [inaudible] of what happens and it's a structure plot. The Greeks have a three-act structure, it's very similar with some constraints around how Greek theater [inaudible] the consistencies of time, place, and action.

[Inaudible] had this idea of like you have to be consistent in time and place and character. The time the show is happening is the time it is happening in the story. So if your play's an hour long, you're only able to show an hour's worth of time. Greeks had no concept of jumping right in time or playing with [inaudible]. All of the action happens in the same place. You have unity of character. This actor is Achilles and will always be Achilles for the sum total of the play. [Inaudible] unite that story and make it consistent and it's the easy structure where people understand what they're seeing.

I think code has some of that as well. If I'm going to talk to an object, I want this object to always be this object. I never want it to be...if it's a user object, a record that's been hydrated in my system as a user, doesn't it also need to do calendaring? Let me talk about that as a separation of responsibilities, a single responsibility principle or a concept should have one responsibility or one job or [inaudible] system and it's the same thing in storytelling. The thing that I'm telling you about the metaphor or illusion or something is you retain that. It should never get mixed with other concepts.

SAM: I feel like now is a good time to mention presentation that I saw at Cascadia Ruby some years ago by Avdi Grimm. It's called Confident Code. It was really educational and transformational for me in that he took the various...he identifies four major responsibilities of a method. It's like gathering information and then it's doing something and then maybe it's acting on the result, and finally it's handling errors. I don't know if I got those four right, but I think that's what it was. But he talks about that in the context of a narrative structure and he illustrates this by...as part of his script, he tries to tell the story but he's telling it in a very hesitant way and going back and saying, "Oh, but before I can tell you that, you have to understand this other thing." And he's illustrating what it's like when you tell a story with elements in the wrong order and how frustrating and confusing it is for the user. I really liked what you were saying earlier too, Kerri, about how getting that stuff right and in the right order is an act of care for the feature reader.

KERRI: I mean, there's self-interest. I want to be entertaining. I want to communicate something. I want to meet my goals. But it's also I want to give you something. I want to give you this gift. 

SAM: Yeah, I mean there's no reason to apply the stuff in Avdi's talk if you don't give a shit about whoever's going to maintain your code later. It's wasted effort if you don't care.

CHRISTINA: You have such an interesting background. And I would love to hear about it more. One thing I want to know is what is that Lackwit Gadabout? 

KERRI: It's a [inaudible] name that I own. 

CHRISTINA: Really? 

KERRI: Yes. 

CHRISTINA: That's really cool.

JAMEY: I love that. 

KERRI: No, years ago a friend of mine used that phrase in a comic that she wrote. And I was like, "Oh, I love it! That describes me so well!" A lackwit is kind of a vaguely Shakespearean term. It means a fool or someone who knows nothing and is happy about it. They lack wit to understand this low-life situation. A gadabout is kind of a [inaudible]. Somebody who tries lots of things, who's a little bit carefree and happy and who has kind of an uncomplicated life or lives only for pleasure and experience.

SAM: The grasshopper in The Ant and Grasshopper.

KERRI: Yeah, exactly. I think of it as a space between gad and about. So, you gad about the field. You go around the field. 

JAMEY: On your motorcycle. 

KERRI: Exactly, like little circles riding around. That's kind of what I aspire to in a lot of ways. I wouldn't say like I venerate the unexamined life. I very firmly believe in this Socratic ideals of the unexamined life is not worth living. I want to blend that with [inaudible] idea of your best life is lived and that you experience the world around you. You approach it in a way that is constantly amazed at the wonder of what we're able to do as humans, what we are able to comprehend and the magic and the majesty of the larger epic landscape upon which we live.

We all have a story of our lives that we tell ourselves and we tell other people we can change the story. We're all looking for a story that is worth living and I feel like I find that when I approach the world with wonder and care and amazement and compassion. In a roundabout way, that's kind of where I get to. Being the lackwit gadabout is to be in that place and to find wonder and amazement at the world around me and to accept it as it is.

CHRISTINA: Can I be a lackwit gadabout too? 

KERRI: Of course. 

CHRISTINA: Okay, thank you. I won't be the original but...

KERRI: You want Christina [inaudible] or...

CHRISTINA: I know right. I love it. 

JAMEY: I also want to be a lackwit gadabout. And I really like it because it reminds me of...I do a lot of tarot and the fool is the first card in the tarot deck. And that was what I was thinking of when you described this because like the fool, he's called the fool which sounds bad but actually it's all about starting new journeys and about wandering. If you look at like the traditional art on the fool card, he's kind of like wearing clacker clothes and like prancing about near the cliff and he's got a little dog with him and I always thought, "What a great life to live." And his card number's zero, like it's before the numbers even start which I really like. And so that's what I was thinking about when you talked about the lackwit gadabout.

KERRI: Exactly. Every classic fool character is the [inaudible] and the one who really knows what's going on.

JAMEY: Absolutely. 

KERRI: King Lear is the classic where like the fool scolds Lear like, "What are you doing? You picked the wrong daughters. You exiled the one daughter who loved you. What is going on here?" It's a wonderful place to be, that carefree dancing zone where you can speak truth and be compassionate and loving and just enjoy life. 

JAMEY: I totally agree.

SAM: So, this is the time of the show where we think back to something that really caught our attention or that we want to try to carry forward into our lives, or something that we want to challenge our listeners to do or to try. I'll just go ahead and start.

You said something really early on in the show, Kerri, that made me think about the distinction between behavior and identity. And that's really something that I noticed in my 20's was that in our culture when we meet somebody, we have this weird thing where the first thing we want to know is what do you do. So we ask people, "So, what do you do for a living?" Or sometimes we say 'for fun' but it's more often for a living because we're a very capitalist culture for some reason. And so, we ask this question in the form of behavior and what we get back is an answer that almost always starts with, "So I am a..." And this has always struck me for 20 years as like being really, really weird. And then you actually told another story a little bit later on, Kerri, about how you got to see the 80's going through this experience of being 'I'm learning code' to 'I am a developer', and it hadn't occurred to me that that could also be sort of a positive aspect of that same bit of our culture. So, those were really interesting. Thank you.

CHRISTINA: I think today I learned or just relearned that storytelling is super important and that it's a skill that I am really looking forward to strengthening. So, thanks Kerri. I really loved everything that you said. You taught me a lot of things. And also, you have like 18 quotables. I was trying to type at the same time but I was like, "I may spoil it. Let me just listen intently." But I really love the line about 'know what your line is going to be, your last line is going to be'. I love that. I'm going to actually put that on a Post-It note. So, thank you.

JAMEY: One of the things I really love about Greater Than Code in general is I feel like almost week to week, we're having this conversation that's just continuous. And so I want to kind of tie some of the stuff we said this week back into something that I was still thinking about from last week's show, which was Jess had said, "You have to care about something before you learn it, that you have to. But it's helpful to care about something before you learn it." I was thinking about that when Kerri was telling the story about Trig. And it really hit home for me again like how difficult it is to be like, "I'm going to learn this because I have to, because I decided that I should care about it and I'm going to read this book," or as Sam mentioned, "Maybe I'm not going to read this book and then I'm going to give it away." And so, I really am continuing to work with this idea about figuring out what you care about and why and then throwing yourself into this learning process which I do feel is the opposite of what we often try to do. You feel like by the time that you care about something, you want to be an expert and that's just not how it works.

KERRI: Everything all three of you have said as reflections, like I could talk through the half hour on each one of those things. For me, that's like let's go and get a pie, let's go and have pie right now, and talk about this over coffee and pie. Is that okay? Can you do that?

SAM: Sounds awesome.

JAMEY: Sounds great.

CHRISTINA: Next time I'm in Seattle, I'm going to call you for a pie.

KERRI: Please do. Anyone who wants to have pie and coffee with me and talk about anything, I'm all for that. I would like to task with the option of challenging people to do something. It's a very small something that you can do every single day when you're writing code that will change your approach to telling stories. And that is next time you do a git commit, gitadd.gitcommit-m and then your little thing, don't do -m. Just do gitcommit and what will happen for most people is a text editor will pop up, usually vim or emacs or something and you'll be able to write extended commit notes around that commit. And the practice of doing that is something I picked up while working with some other people when I was at GitHub. But doing that for most of every commit, makes me tell the story of why I made this change. It attaches, was there an issue, was there a pull request or a bug report? But also like, "What was I thinking? How was I feeling about the change that I just made?" Why are we doing this? Why are we changing this value from 8 to 9? Instead of just using 60 characters, I can write as much as I want to or feel that I need to, to provide the context. And it does a really cool thing when you do your issue, when you make a pull request, it'll look for that and it will paste that in the first one it finds, the extended commit notes as the body of the PR. So, you already had a head start on writing your pull request where you explain the entirety of the context for your changes. And even if you don't end up using that one, you can go through and look at each individual commit in your pull request and you got notes on why you made a change. And you can look for the [inaudible] line of how am I talking about these changes, what is the story that wraps them all together. So, I challenge you to try that, to try using that feature of git for a few days and see how it expands your skill set and your approach to talking about the code.

SAM: I've been doing exactly that on a new project that I'm working on this past week or two. And just yesterday, we fixed a bunch of bugs and I sometimes cheated by just pasting in exception reports, links to the sentry page of the error that I got. But in a lot of cases, it was like 'and we did this because' so that when I come back later and I look at the [inaudible], I'm like, "What the hell?" It helps me.

JAMEY: I one time had to draw a flowchart to explain what I was doing to one of my coworkers. He was like, "Why did you write this code?" I'm like, "I'm sorry. It's so complicated. Let me try your flowchart." And I drew them like a hand drawn crappy flowchart and I sent it through on  Slack. And he was like, "Oh, I get it now." And I was like, "Great! That's that." And then when I went and looked at the commit, he had uploaded my hand drawn chart and like put it in the comments for the code and I was like, "Okay, that would have looked nicer if I had known that everyone was going to look at it for the rest of their lives. But okay." But it was helpful. 

KERRI: Years ago, I worked for this one code base where there was, we called it the K-T Boundary. The K-T Boundary if you don't know is a geological terms for this very thin bands of soil that exists all over the planet. It happens about 60 or 70 million years ago. It is the layer that when the big meteorite hit and killed all the dinosaurs, that's where that soil is from. So it's got like certain properties and we can detect it. So it's the K-T Boundary. Below this boundary, the world is like this. After it, it's like this. And I've worked with so many, so many code bases where there is a K-T Boundary commit that changes the entire world, we change the structure or we're changing from [inaudible] to Rails or whatever it is.

I worked in this one place where there is [inaudible] commit and it was this one commit that on every single file, it touched every single file and it [inaudible] really understand what it was doing. But it had this really long three-paragraph like this is why I'm making this massive commit to change the structure of every single file in this 3000-file code base. It was amazing and I loved it.

SAM: If I remember correctly, the first line of that commit message was [epic whitespace commit of epicness].

KERRI: Yes, that's right. Yeah, you worked on it as well.

SAM: That was Ernie Miller, for our listeners at home.

JAMEY: Well this has been a really great show and it was really awesome to have our friend Kerri on, and I wish that we could talk forever. Saying it like that sounds like "carry on" like we're traveling.

SAM: Maybe we should rename the podcast to My Wayward Sons, so we could have Kerri on our wayward [inaudible].

JAMEY: Oh, darn. We don't do jokes [inaudible] anymore. Oh, so good. Anyway, it was a really great episode and we really appreciate you coming on. So, thank you.

KERRI: Thank you so much for having me. It was great to talk to you all. And Christina, it was great to meet you as well. I don't believe we have met before. 

CHRISTINA: We have not. 

KERRI: Any time you're in Seattle or happen to correspond Ryan as I'm doing this epic four month trip around North America, pie and coffee, we'll make it happen.

CHRISTINA: Will do. Yes, I'm game. Thank you.

JAMEY: And thanks everyone for listening.