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 SK il framework.

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.

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 which 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 tool chain

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.

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

stereotype 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.

Absolutely. appreciate you saying that. And we have 100%

touched on that 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 wasafi. 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 pig

pen.

Oh, we'll definitely get to that.

Well, welcome here. Yeah, welcome

to the show.

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.

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.

I already have a follow up question but Erica will really

Want to hear your definition as well?

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.

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.

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.

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.

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.

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 is it good

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,

yeah. What about What about you, Nick, what do you think?

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

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.

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,

group think and 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 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,

I think it's good.

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.

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.

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. For 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 that 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.

Great, and what about you, Nick? Yeah,

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 I 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. Today's episode of the humans of DevOps podcast is

sponsored by allied collide is an endpoint security solution

that sends your employees important and timely security

recommendations for their Linux, Mac and Windows devices right

inside Slack collide 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 collide educates

them about security, and device management while directing them

to fix important problems. You can try collide with all its

features on an unlimited number of devices, free for 14 days, no

credit card required, visit collide.com/h o dp to sign up

today. That's collide K olid.com/h. o dp. Enter your

email when prompted to receive your free callide gift bundle

after trial activation. And so I'm curious you you touched on

this a little bit in your in your explanations. But the

experience side of me is thinking this 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? 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?

Yeah, I like that, where they you start, 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 and 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's probably five other

people in the classroom who have that same question. We view the

same thing with our open source project.

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?

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 seeing 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.

And then so that that knowledge and that kind of that that

onboarding of the new person has that then impact the software

development itself.

There's a lot of the priorities that we do, we try very hard to

be a community driven, or 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 the

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 that 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.

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.

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 tool chain. So I, 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, in line 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.

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 and now you have the

curse of knowledge.

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

bit. So let's get into that now. Yeah, yeah, let's let's get into

those. Now. I think that's a really good segue to 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?

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 walk through 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.

Yeah, that's great. What and for Eric, now, from your pants

experience, even what were some what are some tools that you

use?

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 tool

chain. 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

off of 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?

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 you hear

the you 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?

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?

So we 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?

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, 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.

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 tool

chain, which is the lead sponsor of the project. But there's

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 tool chain.

From projects big and small companies big and small. It

doesn't matter you their name is there, you could be like them,

essentially.

Well, Eric, Nick, thank you so much for coming on. You've

taught me a lot I came in as as a an outsider to this concept

and I am a beginner and now I feel like I 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.

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,

probably much cleaner than my three year old was.

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. They 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.

That's awesome. That's awesome. And Nick, you you do DIY you do?

What are your DIY,

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.

Awesome. Does your house glow from Can you see it from outer

space?

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.

That's great.

By the way, with website remake project, I mentioned that

there's 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.

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, the concepts of,

of, 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 your your walking

through it.

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.

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.

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