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