On this episode of the Humans of DevOps, Jason Baum is joined by Eric Arellano and Nick Grisafi. They discuss the “curse of knowledge” and how to overcome it, the Pantsbuild project, pigs and more!

Topics discussed:

Thanks to our episode sponsor Kolide!

Narrator 00:02
You’re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas and learning, or the SKIL framework.

Nick Grisafi 00:18
And I think that’s kind of what DevOps is all about, right, like breaking down the barriers, making people self-sufficient. Really just like accelerating the it, process.

Jason Baum 00:34
Hey, everyone, it’s Jason Baum, Director of Member experience at DevOps Institute. And this is the Humans of DevOps podcast. Welcome back. Hope you had a great couple weeks. There we are finally back and live. And excited to be here with you today. So, on the show today, we will be talking about the concept of cursive knowledge. This is a new topic to me. So I’m excited to kind of get into it might be new to you. Maybe you haven’t heard the term cursive knowledge before, but I think the concept once we get into it, you might be familiar with. So the concept of curse of knowledge is where one unknowingly assumes that others have the same insight or background to understand a concept. It’s the opposite of the Buddhist concept of beginner’s mind. But we’ll get more into that later. And with me to talk about cursive knowledge is a panel we’re doing a panel today. This is always exciting when we have more than one guest. Our Erica Yano and Nick are Safi. Eric is a software engineer at toolchain labs. And Eric is focused on empowering developers to build at scale through the open source pants build project. Eric is a volunteer crisis counselor for LGBTQ youth, and aspiring pig parent, which I will also be definitely coming back to later in the program. Erica, welcome.

Eric Arellano 02:06
Thank you. It’s yeah, great to be here. I really appreciate the focus of the podcasts for a brief stint. I was a middle school computer science teacher. And one of the big perceptions that my students had was that tech and software engineering is something that you’re social and like humans, you shouldn’t do stereotypes of the hackers in their garage. And that was one of the biggest things I tried dispelling with my students is no actually modern technology is something that’s extremely collaborative. You’re ultimately building for humans and with other humans. So excited to be here today.

Jason Baum 02:40
Absolutely. appreciate you saying that. And we have 100% touched on that very topic. In fact, you could go back and listen to the episode on VR where we went into the metaverse and its powers because it is such a collaborative environment that we like to have right in the world of tech. So And also joining me is Nick Grisafi. And Nick is a software engineer at rippling with a strong passion for DevOps and scaling processes with automation. On the side, you’ll also find Nick exploring the great outdoors with his dog or tinkering with DIY projects. I also think, Nick, you should probably build Eric’s pig, a pigpen.

Nick Grisafi 03:24
Oh, we’ll definitely get to that.

Jason Baum 03:27
Well, welcome here.

Jason Baum 03:29
Alright, so are we ready to get human and start this panel?

Let’s do it. Awesome.

Okay, so I did my little intro on curse of knowledge. Why don’t each of you take your own crack at defining just what curse of knowledge is? Nick, let’s start with you.

Nick Grisafi 03:51
Yeah, um, so I think for cursory knowledge, when you’re building something, you don’t always put yourself in the shoes of the end-user, right? It takes so long to get to the point to have a stable product, and you know the ins and outs of it. But if you don’t put yourself in the shoes of the person who’s going to be using it, let’s say for that first hour of downloading the product and trying to get up and running. That’s really the most critical point to have adoption, right? That person needs to get something from a proof just an idea to a proof of concept and show that it can do what it’s supposed to do. If you don’t design your tool in a way, where you’re thinking like how can somebody come from nothing to something, then that person could ultimately fail, right? So it’s really important to recognize that you have this curse, so you can adjust and you can build a product that anybody can approach and understand and have one of the best first-hour experiences of their lives and then be able to promote it to everybody.

Jason Baum 04:57
I already have a follow-up question but, Eric, want to hear your definition as well?

Eric Arellano 05:02
Yes, I first heard about the idea of curse of knowledge in the book Made to Stick, why some ideas survive, and others die, which is an awesome book highly recommend. And it’s something I think a lot about as an open source maintainer that view it, essentially, once knowledge is a great thing. But once you have it, it’s really hard to remember what it was like before you knew that thing. So for example, with DevOps, if you’ve been listening to this podcast, you read a lot of books and go to different meetups, and you know, all these different DevOps best practices, you’re trying to convince your non technical manager about why your organization should be using some new DevOps, best practice often feels really obvious and intuitive to you. And it’s hard to remember what it’s like for your non technical manager who might not be totally clear what DevOps is, or what this best practices that it seems obvious, and it’s frustrating, like, Why is this person not getting it, everyone knows that we need to be doing this. without remembering that five years ago, 15 years ago, you didn’t know what DevOps was. And it’s hard to put yourself back in that perspective. So since learning acknowledges, I think it’s made me a lot better of an open source maintainer. And it’s helped our project out a lot to constantly remind ourselves that we have this curse. And we need to be thinking about what it’s like to not have this baseline understanding.

Jason Baum 06:30
It reminds me of when I was teaching my mother how to text. You know, it’s something I took for granted because I knew how to do it. And then my mother had no idea now literally, all she does is text. So yeah, it’s that that institutional knowledge, right, if you pass called the curse, I pass on the curse. Yeah, well, I think we have all heard us on that curse.

Eric Arellano 06:54
We’re talking about like fairly new things here like DevOps and texting, but curse of knowledge is something that might be a fairly new name for a concept that’s always existed. If anyone has heard the allegory of the cave by Plato, I think that can be understood through the perspective of curse of knowledge that gonna mess us up a little bit. But the allegory is essentially that a lot of people are in this caves, and they see these terrifying shadows, and no one wants to leave, and they’re afraid of what will happen if they leave the cave. And then finally, one person is brave enough to do it, they go outside and realize that all they are is shadows, and that there’s this amazing new world out there. But when they come back to the cave, they have an extremely hard time explaining this concept and this new insight to everyone. And they are stuck with this curse.

Jason Baum 07:43
Yeah, that’s interesting, I guess it could be flipped to right. Because there’s a lot of positive when you have that blank slate not Not, not really knowing that institutional knowledge. And then we, we unload all of the knowledge on you. And, you know, I think of I do this a lot on this podcast. But I liken everything to being a parent. And you know, my daughter, and trying to explain concepts to a four year old is very difficult. Because you might use what you’re using words, they don’t even know what that means. Okay, so you’re explaining something, and then you have to explain what that thing is, and so on, and so forth. And then there’s also a beauty of kind of not knowing anything.

Nick Grisafi 08:29
And you always see that referred to online on threads, right? People explain like, I’m five, like, give me the 10,000-foot overview this so I don’t have to think we see that every day in culture.

Jason Baum 08:43
Absolutely. So So then, this is the next question is that? Is it a good curse? Or a bad curse? Sounds like Are you a good witch or a bad witch? Yeah, is it good

Eric Arellano 08:58
or bad? So I think their knowledge we work really hard to get. And we do it for a reason. It’s what allows us to do our jobs effectively. I know, for example, as an open source maintainer, the knowledge that I’ve worked hard over the past few years to understand deeply how the system’s architected, its history and all of the culture behind it has made me a lot more effective. When I want to make a change, I can go in a lot quicker than when I first started working on it as an intern three and a half years ago. I also it helps me when others want to make change that I can go mentor them and help them navigate it at all. So there’s definitely we work hard for that knowledge. There’s definitely some upside to it. But a lot of the downsides like we’re talking about,

Jason Baum 09:45
yeah. What about you, Nick, what do you think?

Nick Grisafi 09:47
Yeah, I agree. And it’s funny because Eric and I were talking about this the other day, and he brought up a concept I wasn’t really familiar with but the bus factor, like at any moment in time, let’s say you’re the person who retains this knowledge What happens if you get hit by a bus? What happens if something bad happens? Right? Where does that put you in your business? Where are they relying on you for certain processes? So I think it’s a good thing, when you have the ability to share knowledge. If everybody can retain and take responsibility and have that be a shared responsibility, then it’s a good thing. But it turns into a bad thing when only one individual maybe retains that knowledge or one specific team. And then problems arise. And if they’re not there to save the day, then it’s a full-blown fire. Right? And that’s nothing. No organization wants that.

Jason Baum 10:38
Yeah, I guess for me, I always love being the new person. Because it’s like, everybody thinks you have a ton of great ideas, because they’ve all been thinking one that you know, groupthink and you’re just set in your ways. And some that no matter how hard you try to not be like you said, you already have that knowledge. But the new person always comes in with like, a breath of fresh air and has all these great, great concepts. And then you fall into the same thing in a few months. So you can only be the new person for so long. Yeah,

Nick Grisafi 11:08
I think it’s good.

Eric Arellano 11:11
I was gonna say I agree. And that’s why a lot of Buddhist circles call beginner’s mind of celebrating that when you come in as a new person, you don’t have all these blind spots yet. And it’s something that we should actively try to cultivate and go back to having that beginner’s mind.

Jason Baum 11:29
So let’s bring it back to kind of to it, and leadership. And maybe you could give some examples of cursive knowledge. And in it specifically, we gave a few that that weren’t in it, and then how does it have and maybe applying to leadership as well.

Eric Arellano 11:49
So I, one example of curse knowledge that we think a lot about with the pants project is our documentation and our error messages of like the what’s the daily experience of our users that we think about power users versus everyday users who power users are people who might be active on GitHub, maybe they aren’t contributing code, but they are in our slack. And they’re reading all the documentation extensively, versus a lot of our everyday users are they don’t really care about the pen stool, we assume that they aren’t reading the docs, they might be newer to programming and might not be as familiar with all the concepts. So we tried to remind ourselves that we have a curse of knowledge when we’re working with our power users. And when we’re doing things like writing documentation, we have confirmation bias of our power user saying Doc’s are good. For example, we want to hear from everyday users. So a concrete example, we had it, this was an error message. Sometimes when you run our tool, Linux will kill the program because it’s using too much memory. And there’s a question of how much detail do we go into on explaining what this is if you already are really heavy into Linux, and tools like this, you’ll know right away what this means. And we can just use a little phrase like, oh, killer, for example. There’s a whole world of engineers out there who don’t and DevOps people out there who don’t have any idea what that is. And we ended up rewriting the error message so that we strike a balance of introducing what the concept is assuming you haven’t heard what this problem is of memory management, but pointing you to other resources so that you can, if you already are an expert, you can leverage the knowledge you already have. And if you don’t know anything about it, you can go to these resources that we link to and learn more about it.

Jason Baum 13:58
Great, and what about you, Nick? Yeah,

Nick Grisafi 14:00
I think Eric’s example of error messages is super important. I’ve even heard people in the industry talk about switching programming languages, like let’s say from Python to go, just because they have better error messages and things are more clear. And documentation makes sense, right for the beginner. So now I’m seeing things like in Python community happening, newer releases, where they’re just improving, improving error messages, improving stack traces, to make things easier for that beginner or anybody who’s just new coming in who might not fully understand what’s going on. So yeah, I think that’s a perfect example, like documentation. Use Case always explain things or point to resources so people can figure out what’s going on. Not sifting into the internals and trying to figure out what calls actually made and then all that time you spend researching that knowledge, like save do click Save the research, just go here and figure it out that type of thing.

Jason Baum 14:54
Today’s episode of the Humans of DevOps podcast is sponsored by allied Kolide is an endpoint security solution that sends your employees important and timely security recommendations for their Linux, Mac and Windows devices right inside Slack. Kolide is perfect for organizations that care deeply about compliance and security. But don’t want to get there by locking down devices to the point where they become unusable, instead of frustrating your employees Kolide educates them about security, and device management while directing them to fix important problems. You can try Kolide with all its features on an unlimited number of devices, free for 14 days, no credit card required, visit Kolide.com/HODP to sign up today. That’s Kolide.com/HODP. Enter your email when prompted to receive your free Kolide gift bundle after trial activation.

And so I’m curious you touched on this a little bit in your explanations. But the experience side of me is thinking this sounds awful, like the beginning of a user journey, a customer journey or roadmap? You know, what’s your? What’s your first six? How do you get it? How do you start? You know, where’s the start button? Where How do we learn? How do we go from that to the next step to the next step to the next step? So how does that you know, explain the dynamic maybe between open source developers, their lead sponsors of the software and then with customers in the developers who use it?

Eric Arellano 16:37
Yeah, I like that, I think that’s been the most important thing for our project is inviting people to actively share their feedback, especially if you are a beginner. If you go to pantses docs, you’ll see that we have on almost every page an invitation of like, hey, we’d love to hear your feedback, what is confusing, you can join our Slack reach on GitHub. And we often we find that newcomers are often hesitant to share their feedback. They think that they’ve heard from a couple of people to say like I haven’t used enough time to actually like want to share my opinion. And we explicitly name this idea of curse of knowledge and say, No, we are so grateful for your feedback, because that is exactly what we want to hear. And we also assume when we have a user who’s sharing feedback and is confused about something, there’s probably like 10 other people, at least out there. It’s like when teachers always say in school, if you have a question, you should ask it because there are probably five other people in the classroom who have that same question. We view the same thing with our open source project.

Jason Baum 17:41
So glad to use that example. Because that’s that’s exactly where my head went. Yeah, I said that. What about for you, Nick?

Nick Grisafi 17:49
Yeah, I think the collaboration piece is super important. Like if you search anything like Python model, repo build system, like, and then let’s see that first intro blurb for pants, that’s your gateway, right? That gets you into it. And then once you have a community and collaboration, that it’s very open and welcoming, you just kind of just get even more interested and you want to help like these people because they really helped you. And it is just a really positive experience. And I think that’s kind of what DevOps is all about, right, like breaking down the barriers, making people self sufficient, really just like accelerating the IT process. So I think what pants does is an example that a lot of open source communities can follow to have a successful project.

Jason Baum 18:37
And then so that that knowledge and that kind of that onboarding of the new person has that then impact the software development itself.

Eric Arellano 18:46
There’s a lot of the priorities that we do, we try very hard to be a community-driven, or sorry, community-driven project, that it’s open-source, so anyone can contribute what they want. maintainers also do try to listen to what users are asking for. And so a couple concrete things. One is prioritization, that whenever a user has new feature that they want, we ask them to create it and GitHub and so we can track it, and then either recruit someone to implement and help mentor them, or pick out ourselves. Another thing that we view is when we have this idea of like a Doc’s bug, that when our documentation is confusing, we take to try to take that seriously. And don’t just view that as like, oh, they didn’t understand we instead view that that that’s a problem in our documentation. So we’ll open up a ticket or either direct it or fix it directly of needing to go and rewrite what people found confusing.

Nick Grisafi 19:50
Good first picks documentation is usually a good first pick. Yeah, yeah. Yeah, just reading through the docs and then having like for pants For example, it’s like their docks allow you to give feedback right there. And I think I’ve abused that feature a bunch of times. And I think for other newcomers, it’s a safe way to just get involved. And when they accept your, your change, it’s a really exciting experience. And you just kind of want to keep doing it.

Eric Arellano 20:16
So I first started using pants as an intern at Foursquare about three and a half, four years ago, wasn’t contributing at all to it, it was just another tool I had to learn on dozens of other tools. And then I was trying to do a change to migrate the company to python three, and it ended up being that pants was a blocker for us. So I opened an issue on like, hey, what would it take for me to migrate pants that I don’t really have much interest in, but it’s gonna unblock me from this project I really want to do community was really supportive and fell in love with the community. And then started contributing and led that project and then worked on the project for Twitter and now toolchain. So, I try to think a lot about my experience when I was an intern, and constantly remind myself of it that to be honest pants, we rewrote pants, inline launch pants to about a year and a half ago, which was a ground-up rewrite. And at the time, when I first started using pants as an intern, the other interns and I didn’t really get what the tool was for when we thought that it wasn’t super intuitive and was sometimes clunky, even though it’s trying really hard to do good things. And I, that’s my personal goal now with pants is that it is so intuitive for beginners and for summer interns, that they don’t that they know already why it’s worth using.

Jason Baum 21:49
That’s, that’s great. So you, you kind of you came in as that the original concept, right? And you didn’t really know that much about it. Sorry, forgive the Buddhist term. Beginner’s Mind, beginner’s mind seeing your mind. And now you have the curse of knowledge.

Eric Arellano 22:07
Exactly. Yeah. And I try hard to remember what it was like to go back. By its, I still have blind spots that I have to which we can get into in a little

Jason Baum 22:18
bit. So let’s get into that now. Yeah, yeah, let’s get into those. Now. I think that’s a really good segue to that next question. So you went from a beginner to now you’re, you’ve got the curse of knowledge. And Eric, why don’t we come back to you? Because, Nick, I don’t know if you have I mean, we’ve all had similar experience, everyone starts New and then becomes an expert in whatever and maybe not an expert, maybe that’s the wrong word, but as curse of knowledge, right? So what are some things you could do to go from having that curse of knowledge now back to that beginner’s mind?

Nick Grisafi 22:57
Talk to people, you gotta you got to the moment that anybody raises an issue like they’re having a problem. And that’s the moment that you should go in and communicate with them understand the problem they’re having, and document it. It really helps like in the remote world that we’re all in. So just get on a call with somebody, have them share their screen, and then actually walkthrough and help them. One practice that we do a lot at rippling is we have a channel where we try to keep all the context for developer issues. And then there’s like a ticketing system, and we track it. And whenever something new comes up, we immediately try to document it. And then we have automation that could come in if a similar question is asked, we immediately post the documentation. So they know. And for me, that’s a good way. The moment that somebody has an issue, I get on a call, I actually realized like, oh, yeah, that’s really not supposed to be half a day. Okay, let’s make sure this is a document that so it doesn’t happen again. And then that kind of like brings me back into their shoes. And then just seeing like, the human aspect of that, like, they’re really trying, they’re not just sitting there and like throwing stuff at the wall, but really trying to figure out what’s going on here. So I think just communication is key to just talk to people.

Jason Baum 24:15
Yeah, that’s great. What and for Eric, now, from your pants experience, even what were somewhat are some tools that you use?

Eric Arellano 24:24
Yeah, so I don’t to Nick with talking to people. And I would add talking to people with diverse experiences, including people with less experience. One of the things I was really excited about this past year was to mentor and turn it toolchain. And I find right now with recruiting that a lot of companies are primarily targeting senior engineers, which are important to any organization, but I think that the industry would do well to go out of their way to support and bring on more junior engineers and more interns and recognize the asset that the As engineers bring to an organization and the perspective that they bring. Another really useful technique that we’ve used is, when we are trying to re-envision a part of pants, we often do an exercise where we intentionally disregard all 10 years of history of the project, all prior art. And we think if we were to do this from brand new without precedent, what would be the best design and the most intuitive design? And once we figure that out, we then invite back in the precedent and technical architecture and everything and try to figure out okay, how can we rectify these two, and make this actually happen. And that’s where the knowledge that we do have is incredibly useful, that we can often figure out based on our experience, this is how we can make that vision happen. To create division, we find it’s helpful to consider what would we do if we did this completely?

Jason Baum 26:01
Yeah, that one, I really, I really liked that example. I mean, they’re all great examples, but that that one resonates, because I feel like sometimes we do the, okay, if we’re going to make this decision in a vacuum, what would it be? What would it look like, right? And we always hear that being thrown around a lot. And that sounds great. But you can’t make a decision in a vacuum, you have all these preconceived notions, you have these rules, you know, whatever. It may be about why you can or can’t do something, but then I think, coming up with it in the vacuum, and then going back and saying, Okay, if we were to stretch to get to this, how would that look like? Take some work, right?

Eric Arellano 26:42
Yeah. And I think it’s an important nuance that I mean, we’re an open source project organizations depend on in teams depend on that we do need to care about backwards compatibility, and offer a good story there. So yeah, it’s a tension between we want it to be as intuitive as possible for newcomers, we also have these decisions were tied to that don’t make as much sense now. But they made a lot of sense five years ago or two years ago. So how do we rectify both of those?

Jason Baum 27:11
So we discussed, you know, the Buddhist concept of beginner’s mind, and how that kind of helps overcome the curse of knowledge. And those are some great tools. Now, here’s the new term, the power of the outsider. So can you explain that a little bit? And then, you know, how does it relate to all of this?

Nick Grisafi 27:33
Yeah, I think the power of the outsider for pants itself, is exactly what Eric was saying earlier, just having people come in and tinker and use the product in a way that maybe they never even thought of before. And that kind of shows them that there, there actually is value there, right there. There could be value if we design the tool to work that way. So what that could drive is decisions, you know, let’s say for their yearly planning and say, Hey, like, we want better incremental adoption, because people going from no pants to wearing pants have to incrementally get there, right. And so I think the power of the outsider is just that feedback loop that is absolutely critical for any project to succeed, whether it be an open source project, or an internal like product that you’re building for a company, right? We have testers, right? We have people that will use the product and give us feedback right away, we take that feedback very seriously. And they’re the ones outside of the org, right? They don’t see how we build it. And they might even use the product in a way that we never thought of. So we got to take that seriously and tap into that knowledge of the outsider.

Eric Arellano 28:47
Yeah, and just I loved your episode a couple of weeks ago about silos and remote work. I think that’s very relevant here. One of the important things that we as an open source community have tried to focus on is making sure that the community is represented by multiple organizations. I work for toolchain, which is the lead sponsor of the project. But there are multiple organizations that are both active users and also have active maintainers. We found that having that diversity of stakeholders has made the project overall more resilient and brought in new perspectives that we wouldn’t have considered if it was the only toolchain.

Nick Grisafi 29:24
From projects big and small companies big and small. It doesn’t matter you their name is there, you could be like them, essentially.

Jason Baum 29:32
Well, Eric, Nick, thank you so much for coming on. You’ve taught me a lot I came in as an outsider to this concept and I am a beginner and now I feel like I do have not a lot but I have some of that curse of knowledge on the topic. I know enough to be dangerous as some people like to say All right. Okay, we have to touch on the pig real quick. Yeah, absolutely. Eric, tell me a little bit about the pig.

Eric Arellano 30:07
Yeah, so I would love to eventually adopt some pot-bellied pigs. They’re extremely smart. A lot of people say that having a pig is like having a three year old toddler. And actually, a lot cleaner than a lot of people realize if they like they can live indoors as long as they have some outdoor space,

Jason Baum 30:27
probably much cleaner than my three year old was.

Eric Arellano 30:31
So there’s this really cool sanctuary down in Tucson called the Ironwood pig sanctuary. And one of the fun projects I did last year was that they had a website written in literal HTML and CSS from 2002. Someone generously donated back in 2002. They’ve been using this website for 20 years. So I remade their website using Squarespace and the sanctuary with 650, pot-bellied pigs, that a lot of people when they adopt a pig breeders will lie and say that there are many pigs or micro pigs or teacup pigs. They’re not actually their baby pigs, and the readers will say they won’t be more than 40 pounds. They often grow up to be up to 150. And people don’t clear it with their HOA or don’t realize like what it takes to have that big of a pig. So I think it’s something like 95% of people who adopt a pet pig end up giving it up for adoption. Wow. Amazing. Yeah, yeah. No fun for the pig. Amazing sanctuary, I love to visit pretty close to where I am in Phoenix. And they have this like sponsor a pig, where they’ll write you letters about your pig, and so on.

Jason Baum 31:43
That’s awesome. That’s awesome. And Nick, you do DIY you do? What are your DIY,

Nick Grisafi 31:51
more recently, like home automation. So having an internal Kubernetes cluster, running all the home lab jazz, you know, a piehole, all that good stuff. We like to do internal development or like side projects, right. And this is just like a platform that we can use to experiment and test on. And I think it’s it’s pretty amazing. Like all the open source tools out there, you’re like you could get from zero to almost being like your own cloud provider. It’s pretty amazing. So now we got like, a bunch of computers in our house like being shipped all over from our friends, like any part that we could get and just add a note to our cluster and extend it out. Like we’re really trying to do that. And it’s a lot of fun. Like you learn a lot of cool practices while doing it.

Jason Baum 32:36
Awesome. Does your house glow from Can you see it from outer space?

Nick Grisafi 32:40
I could change my lights in my room a daddy. So that’s all from one dashboard. Yeah, but I think that next step Yeah, glow from outer space. And then we’ll have like the pigs. Yeah. Advertisement be up there. And you know, they don’t Yeah.

Jason Baum 32:57
That’s great.

Eric Arellano 32:59
By the way, with website remake project, I mentioned that there are a lot of organizations out there where they’re awesome at what they do. Like the six people who run the sanctuary are know everything there is to know about pigs. Technology’s a little overwhelming to them, kind of like Jason sounds like your mom with text messages. So even if you’re not a software engineer, you there are a lot of opportunities of like, all I did was set them up with Squarespace. I didn’t program anything. And then I set them up with like, new email. die a lot of organizations would love your help with tech, even if it’s not actual programming.

Jason Baum 33:35
Random Acts of Kindness. We discussed this with Gotham palapa, and his new book on, on empathy, and it’s, yeah, I think everybody could find something that they could do to contribute to do something to kind of give back. So appreciate your saying that Eric and Eric and Nick, really appreciate you coming on the show giving us some of your time. And, and teaching us all about you know, about this whole I mean the concepts of curse of knowledge and the power of the outsider and beginners and I mean, geez, there’s a lot of new concepts thrown at me. So I really appreciate you walking through it.

Eric Arellano 34:17
Yeah, absolutely. Thank you for having us. And now I’d also We’re a friendly bunch on the pen Spode Slack. So even if you don’t want to use the technology or anything like that, you just want to talk more about this, we’d be happy to have you join.

Jason Baum 34:28
Yeah, that’d be great. I would love to jump in. Awesome. And thank you, to our listeners for joining us for this episode of the Humans of DevOps Podcast. I’m going to end this episode the same way I always do, encouraging you to become a member of DevOps Institute to get access to even more great resources just like this one. Until next time, stay safe, stay healthy, and most of all, stay human, live long and prosper.

Narrator 34:54
Thanks for listening to this episode of the humans of DevOps podcast. Don’t forget to join our global community To get access to even more great resources like this until next time remember you are part of something bigger than yourself you belong