This episode of Greater Than Code was sponsored by Alt::BrightonRuby, a slightly odd, quasi-conference for strange times by Andy Croll.

There's no in-person BrightonRuby this year, but Andy is still trying to bring Ruby-ists and other software folks together.

It will be recorded talks, a physical book, and a podcast. Delivered throughout June and July of 2020. Plus a donation to Shelter's Coronavirus appeal.

Tickets are on sale now for 29Euros plus tax (which works out to a very affordable about $36.50+tax in U.S. dollars!) 

You can find out more information, see all the speakers and get your tickets at https://alt.brightonruby.com. 

P.S.: A trusted source tells us that the book is a beautifully typeset copy of Why's Poignant Guide.

REIN: Hello and welcome to Episode 183 of Greater Than Code. I'm your co-host, Rein Henrichs, here with my co-host, Jamey Hampton.

JAMEY: Thanks, Rein. And I'm here with our guest who I'm very excited about, Vaidehi Joshi. Vaidehi is a senior engineer at DEV, where she builds community and helps improve the software careers of millions. She enjoys building and breaking code, but loves creating empathetic engineering teams a whole lot more. She's the creator of basecs and baseds, two writing series exploring the fundamentals of computer science and distributed systems. She also co-hosts the Base.cs Podcast and is producer of the BaseCS and Byte Sized video series. Welcome to Greater Than Code, Vaidehi.

VAIDEHI: Thanks, Jamey. I'm so happy to be here.

JAMEY: We're really happy to have you on. I'm going to get right into our first question, which you're probably expecting, which is what is your superpower and how did you acquire it?

VAIDEHI: My superpower is that I'm very good at learning new things and then teaching it to other people, which is basically like regurgitating information, distilling it in a new format. But I think I'm pretty good at that. And I think I just acquired it by doing it a lot and being pretty good with words and communication. I feel like it's like a boring, very pragmatic answer, but I am good at that. [Laughs]

JAMEY: Pragmatic is good. I think I would agree that you're good at that. I would say that you're known for being good at that, in fact. I think you've taught a lot of people a lot of things, which is awesome.

VAIDEHI: Yeah, I have that going for me. So that's good.

JAMEY: I've heard the advice before that people have given, particularly for people that are new speakers at conferences and such like this, that the idea that teaching something helps you learn it. Just pick something you want to learn about and agree to give a talk about it and then you have to learn about it. Would you say that this is related to the way that you feel about that?

VAIDEHI: I think so. I definitely agree that a really good way to learn something is to be put in the position where you have to teach it, because then if there's anything you don't know about it or if there's any gaps in your knowledge, that is going to really become very clear when you try to teach it to somebody else. And so, I think it's pretty good motivator. But as far as the tactic of learn some things so you can explain it at a conference in your talk, it's a little scary, but it's actually effective. And I've done it. It's scary once you get the talk accepted and you're like, "Oh, no. I got to go dig into this and figure out what is going on here." But it does work. I can definitely say that it works.

JAMEY: Do you decide topics that you're going to cover on BaseCS and your other series? Do you decide on topics of things that you want to learn about?

VAIDEHI: Yeah, that's actually totally how it's motivated. It's basically like what are the things that people are talking about that I don't know and that I wish I knew. And let me just make a list of them and I'm going to go learn about them. And I know nothing about them going into it ahead of time. And sometimes I'll start learning about something and I'm like, "Oh, actually, I need to go learn about these six other things first. I don't have the building blocks to learn about this yet." And then I'll come back to it. But it's basically like, "Oh, what is this problem that people keep talking about?" I want to learn about it with no context and then trying to figure out what I need to do and what I need to know to learn about it.

JAMEY: I think that's awesome.

VAIDEHI: Basically, I'm motivated by knowing what people are talking about. And I hate being the person at the table where -- I don't know if you've ever been in this situation where you're in a conversation or in a room and everybody's referencing something and you're like nodding along like, "Yeah, I know what you're talking about." And then in your head, you're like, "I do not know what you're talking about." And that's like a big motivator for me because I don't like that feeling and I want to know. And so then I go home and I'm like, "What were they saying?" I need to go figure it out and fill in that gap because I don't like to be out of the loop. This is really like the theme of my life: Don't leave me out of the loop.

But I guess I'm curious to know, how do you all teach yourself new things? Because I've sort of figured out that I have my own tactics and pattern, but I'm always curious to know if it's the same as other people or if you do things that are really effective for you when you find yourself in the situation where you have to learn something that you don't really know that much about. So, how do you approach that?

REIN: I read a lot, which is sometimes difficult for me. And then the thing that I think helps the most is relating new things to something I already know. I also try to find ways to experience things, put things into practice, not just have them be totally theoretical.

VAIDEHI: Oh, yeah. That's so important, I think. I find myself when I'm learning something, like a few minutes into it, I'm like, "Okay, but why? Why do I need to care where it is actually applied?" Because otherwise, I'm out. That's my hook to keep learning. And so when I'm learning something, it's like you've got to give me a reason. What is the practical example of this? I don't need to build it yet, but I need to know why. But yeah, I totally get that. The practice is so important. It's not just theory.

REIN: Also a while ago, a friend of mine taught me a secret for reading papers, which I've used, which is you start by just reading the abstract and the conclusion of a paper you're interested in. Then you just sort of mentally file it away. Unless you're really interested in them, go ahead and read it. But who has time for all of that? But what will happen is at some point in the future, you'll come across a problem and something will click and you'll go, "Oh, I have a paper. I need to read about that." And then you'll go read the paper. And when you do this in public, you will look like a genius.

VAIDEHI: Ooh, I like that. Well, mostly because I feel like it lowers the barrier to entry for reading white papers and stuff for me, because I just get a little overwhelmed. But if it's just like two paragraphs, I can do that. That's easy. I'll skip the formulas. It's great.

REIN: It's hard to know what's going to be relevant to you. If you're obviously interested in something, just go ahead. But if you're just skimming through stuff or trying to get a breadth of information, this is good.

The other thing he taught me was when you actually read a paper, try to pick fights with it. Look at some of their conclusions and examine the premises and say, "Why do these premises exist? Why do they have to be this way? What if you change them?" And when you that, you'll generally find one of two things. One is you'll figure out something you didn't understand about the paper that made it have to be that way. Or two is you'll figure out something they didn't understand and have a novel result and then you can go publish that. That hasn't happened to me yet, but it's perfectly possible.

VAIDEHI: That's cool.

JAMEY: I agree with what you're both saying about practically applying things being really helpful. I find it tough to learn very theoretical. I also find it tough sometimes, I really like to learn new things, but I find it kind of tough to kind of self motivate myself to learn new things if there's not a specific reason, which is why that conference trick kind of works on me. Like now there's a deadline and a reason that I have to do something by a certain time. And that's very motivating for me. I think that sometimes if there's like a concept I really want to learn, I'll come up with a little personal project that uses it. So I'm like, "I have to learn this to get this to work," rather than just like, "I have to read this because it'll make me smarter." So, I find that a lot easier. And I find that tutorials are very helpful for me. I find just like reading a paper kind of hard to ingest. I find learning from technical talks is pretty difficult sometimes because I really want to be doing the steps at the same time that I'm learning about them. Like sitting in a conference hall, I can't really do that. So I'm very, very into tutorials where it's like, "Okay, now do this," and then you learn something else. "And now do this." That's how I learned Rails.

VAIDEHI: Yeah, totally. I like what you said about having a motivating driving reason. I think I need that too. I could even take it a step further and say that I sort of need to be held accountable for my learning. I don't know what that says about me. But whenever I have learned something similar to what you said with the conference talk idea, I need accountability. And so, when I was learning computer science for basecs or distributed systems for baseds, I had to basically tell people, "Look, I'm going to learn one new thing a week and I'm going to write about it." I don't know that if I hadn't said it out loud or in my case, tweeted it, that it would have necessarily happened. It's very hard to motivate yourself to learn so many things back to back to back, even one thing. It's just hard, especially when you realize that you don't know anything about it and you need to, like now, load all this context into your brain. Even if it's not super publicly, just setting a deadline for yourself or just telling someone on your team, "I'm going to learn how the router works this month. And at the end of the month, remind me to tell you how it works." And then you're accountable to somebody else. So, I think that's super helpful. And if you're somebody who needs structure, I found that it really helps.

REIN: One other thing that has been really helpful for me, especially with --distributed systems papers are hard. Notoriously hard. The reason a Raft exists is because Lamport is hard to understand. Like Paxos is a mess. It's a beautiful mess, but it's a mess. And so, I think I did very early on was we started, some friends of mine and I, we started like a paper club. We would get together and read a paper and then talk through it. Kind of like a book club. And this was so helpful because we each got different things out of the paper or we're strong in some places and weaker in other places. And we complemented each other really well. So when I didn't understand something, someone else could probably explain it to me. Sometimes I could be the one doing the explaining, less often than maybe I would have liked. But it was really helpful.

VAIDEHI: Yeah, I would like to add one other thing about papers, which is that if you don't have a background in, I guess, computer science or if you didn't study a STEM field academically, like I did not, then you have this added barrier where you have to learn how to read those papers. Because I learned that a lot of the reason why it was difficult for me to understand some of these computer science and distributed systems papers is that they're structured in a certain way and there's like a little bit of an art to learning how to read them. And I would feel really stupid because I would be like, "I have read this paper twice. I don't understand it." Talking through it with somebody else who actually had some experience doing that really helped. And that made me feel better because they explained to me like, "No, it's not the concept that's that hard and you're not stupid for not understanding it. It's that you haven't read that many of these papers. So this is just like a whole new thing for you." And so, I love the idea of having a paper club because I'm sure that it's not necessary that the paper is necessarily insurmountable. It's just like, how do you actually make sense of it?

REIN: I didn't go to college, so there was a full at least a year for me where I was just running up against the wall, trying to read a paper and bouncing off. And one of the things I learned, sort of a secret that I learned that really helped me is you don't actually have to understand the equations or the proofs. They're just there to convince the other professors.

VAIDEHI: [Laughs]

REIN: You don't need to be able to verify, like walk through a proof in your mind and verify it to understand the paper. That's just there to convince other people. That's all the proofs are for, is convincing people.

JAMEY: Yes. You just changed my mind on papers right now. I just had an epiphany. It's okay to just let your eyes glaze over things and be like, "Ah, yes. That looks true. Someone approved that to me in this paper." 

VAIDEHI: Sometimes they'll also bold things too, the important parts. And I'm like, "Oh, good, I'll just read this bold text."

REIN: The whole reason those things exist is so other experts can be like, "Ah, yes. I agree. That's it. That's why they exist. That's why they're in the paper."

JACOB: It comes down to what your goals are. If your goal is to absorb knowledge and you're willing to assume that this knowledge is true without questioning it too deeply, then yeah, I wouldn't be too concerned with the proof. But like you said, if your goal is to make sure that a paper with spotty reasoning doesn't make it through in sort of the larger canon of knowledge, then I would be wanting to read the proofs. But if that's not my goal, then I don't need to.

REIN: There is a great Stack Overflow answer. And the question was like, given that there are sometimes errors in proofs in published papers, why doesn't the entire machinery of formal mathematics collapse? And the answer was because the machinery of formal mathematics is based on human networks of trust and not on algorithmic detection of errors. What very often happens is that the sum proof is technically wrong, but morally correct. And someone just comes along and fixes it.

JAMEY: Does anybody listen to the show, it's a YouTube show called Unraveled? Does anyone know about this?

VAIDEHI: I haven't. I'm curious to hear about it.

JAMEY: It's a video game show. It's like a comedy thing. But the host of it, his name is Brian David Gilbert, he does really intense research about video games and then does these weird presentations about like -- I researched every single Mega Man character that has ever existed in any Mega Man cannon. And he'll do like hours and hours of research in all this weird stuff. And so I think about that. And he'll make jokes about it when he's giving his presentation, like, "Oh, yeah. I read Skyrim books for 240 hours to make this video. So that was my process." And I think about that sometimes when I'm working on talks and stuff. I did a talk where I ended up reading the entire 2016 US Census of Agriculture for demographic information for this talk on user empathy that I was writing. I'm like, "Eh, I felt like this guy doing these Unraveled videos and doing hours and hours of research about video games." I did make a joke in it in my talk, like, "A really riveting stuff. I read this entire paper." People laughed and it made it feel better to me. And now, when I'm doing a lot of research, I just think about that. Maybe that's really silly.

JACOB: I think that makes sense.

VAIDEHI: Yeah.

JAMEY: I'm doing research and I'm going to tweet about it. It makes it feel less like work. I don't know.

JACOB: Yeah, you put yourself on the hook. I've never been good with "self projects". I think the places I learn best is when I'm on the hook with someone else, even if it's sort of something small. And so I think, what you're saying is like you are under pressure, at least a little, to say something in public that can clearly articulate your ideas. And that pressure, however small, sort of gets you to maybe do your best work. I don't know if that's the case with you, Jamey, but that definitely is the case with me. I would definitely do make more effort to make sure I've fully research what I wanted to say and that I'm fully articulated at them.

VAIDEHI: Yeah, it sounds like the accountability thing.

JAMEY: For sure. I also feel a sense of camaraderie, I guess, with other people that are researching things in this way, is what I'm getting at a little bit.

JACOB: For me, I really like the concept of understanding the problem, like really feeling the problem that the thing I'm going to be learning solves before I learn it. I was doing a tutorial recently on how to build a calculator, just enter a mathematical expression and write a program that can interpret it and put out the right answer. And I was following it and I was like, "This is really boring." It's not terribly interactive. I'm just sort of following along what this author is writing. And so, what I decided to do is sort of take the problem of like, "Okay, I want to add 54 + 22." I'm going to try to just solve it myself without reading the article and sort of just experience how deceptively difficult that is. Even though it felt like, "Oh, I could do this in an hour." And then find that it was actually more challenging than I had thought. And then I think it was the practice of gaining an appreciation for the problem and just engaging with it, even though I kind of failed miserably at it, that when I came back to the article, I had the context of the problem sort of more deep-seated in me. I was able to read the material a little more actively.

REIN: I think it's totally okay to bounce off something a few times before you're in the right place to understand it. That's happened to me a few times.

VAIDEHI: I think it's pretty common for learning anything, now that I think about it. If you think about software, any kind of concept in software, when you're learning about something the first time you have one perspective on it, but then you sort of encounter the next time and you have a different perspective and you sort of are going like in a spiral towards the center of whatever it is that you're learning about. I think there's actually a concept called the hermetic circle or heuremetic circle or something like that. I cannot remember what it's actually called or how to pronounce it. But it's this idea of like, you keep approaching the truth a little bit closer each time and getting closer to the center, the kernel of it. And it's interesting when we talk about like, "Oh, I'm bouncing off of this concept for when I'm learning about it," but it's actually like, is it bouncing off or is it just you're just not quite epicenter yet but each time you encounter it again and again, you're getting a little bit closer. Because if you think about software careers, people encounter the same concepts throughout their careers and they have a different perspective on it and they teach it differently. And then they know a little bit more about it and they go into more and more depth the more that they learn about it. And so, it's like you sort of pick up something different each time that you bounce up against it, if that makes sense. 

REIN: Hermeneutic Circle. 

VAIDEHI: That's it. Yeah. [Laughs] I was like, "There are some E's and some R's and an M." 

[Laughter]

JAMEY: I really love that because I love the implication that I totally agree with that even if you are working on learning something and you don't quite get it, it's not a waste of time. There's a story from my own life that I think about a lot when I'm kind of bouncing up against stuff in that way, which was the first time I was ever trying to learn HTML. I was probably 11 or 12. And I was trying to put frames, old-timey HTML frames where you have like the sidebar that scrolls. And I read all of these tutorials and I just didn't get it. I was just staring at this tutorial. I don't understand what they're asking me to do and I can't do it. And I got really frustrated. And then like a week or so later, I was doing something completely different. And all of a sudden my brain was like, "Oh, my God, remember that thing I read about frames a week ago? I understand what they meant now suddenly and I don't know why." And then I went and did it. So I think about that a lot when I'm bouncing up against something at work or people say, "Walk away from the computer and then come back and let your brain kind of rest." I totally believe in that. I think about that in that context. Like, I read this, I didn't understand it, but it wasn't a waste of time. My brain is going to keep percolating on that in the background. And at some point, I'm going to be glad that I did this attempt at learning, even though it didn't work out the way I wanted the first time.

VAIDEHI: Yeah, I think that's really true, especially the thing you said about your brain percolating. I'm a firm believer in mental marinade where when I'm like working with other engineers and they're like, "I don't understand," or I see them struggling. Obviously, it happens with me too where I'm just, "I don't get it," and walk away from my computer. And it's like over five days, I'm not thinking about it. But actually somewhere in the back of my brain, my brain is thinking about it. It's like marinating. And then I come back to work, like on a Tuesday and I'm like, "Wait. Of course, I never tried this thing." And then obviously, it works or I have a different perspective on it or I know what to Google the next day. It's so important to let it just take the course it's going to take because you will circle back to it and be a little bit closer, or at least I feel like it'll be a little bit closer. Maybe sometimes, it takes longer than other times.

JACOB: I think for me, when I'm in that sort of stuck space that I've been working on really hard, I'm trying to solve the problem that I've decided is my problem. And I think the walking away remedy works really well because I think it helps you remember, like you forget the problem that you thought you had to solve and you remember the actual problem you had. And in a lot of cases, instead of how do I solve the problem? Like, capital S solve the problem, which if you're like me, you initially come up with the most engineered solution you can think of. And instead, when you sort of forget about it, your brain instead finds a way to not have the problem instead of how to solve the problem, if that makes sense.

VAIDEHI: Yeah, I think I've experienced that, too, where when I come back to something, I'm like, "Wait a second, what was I actually trying to do? Because maybe I've made this harder for myself than it really should be." And I backup six steps and be like, "Let's just start from here again." And a lot of the times, I've over engineered it because I've just spent too much time looking at one part of the problem that I thought was a thing and it was not the capital T thing. So, I totally get that, too. And I've experienced it so many times. But I think I'm getting better. As my career goes on, I'm getting better at recognizing those signs of like, "This should be a moment that you get up and walk away," because you're spinning your wheels and this is not productive for you. And you probably just need to take a step back. Almost every single time, I've been right about it. So, I probably should just do it sooner than I think.

JACOB: And in a lot of cases, sometimes where you end up is like, "Oh, maybe I don't even need to solve this problem at all." Because if it's a question of like, "I want to learn why this doesn't work," then, of course, that's the only way. If it's something for work, it's like, "Oh, maybe we didn't actually need to solve this problem. Maybe I can put a hack in at work because it's going to change in a week anyway." 

JAMEY: I do all of my best thinking in the shower. When you're talking about walking away from the computer, I will take a shower that I don't need just to do good thinking. So basically, whenever I'm working on a really hard problem, I'm just very clean all the time.

VAIDEHI: [Laughs] 

REIN: Jacob, when you said that maybe you're working on the wrong problem, this reminds me of something that Russell Ackoff talks about, which is that there are a few different ways that you can try to deal with a problem. He has four categories. One is, he calls it absolution, which is you ignore the problem and hope it goes away. Two is resolution, which is you try to do something good enough. This is often like a tactical approach to solving the problem. Then there is solution or you try to find some optimal solution. This often involves like experimentation or research. But then there's dissolution. And what this means is that you redesign the system that has the problem so that the problem no longer exists.

JACOB: Exactly. Yeah, that is a great way to put it.

JAMEY: That gets me curious about the first one you said, I believe, was ignore the problem and hope it goes away.

REIN: Pretty common, actually. [Chuckles]

JAMEY: But I'm wondering if there are times when that actually is the right thing to do. Like, put a moral judgment on it.

REIN: No, that's not a moral judgment. So in risk management, in security, there are different ways that you can mitigate a risk. And one of them is to decide to not care about it. And that's a legitimate thing that you can do. You can say, "Yes, this risk exists. No, it's not worth correcting or mitigating."

JACOB: Turns out this is a great problem for parenting, for sure.

[Laughter]

JACOB: You might laugh at, but there's a lot of things that my wife and I have realized, like does addressing this thing with a three-year old, is it actually necessary for (A) his development, (B) our sanity. That's a bad word. Our emotional well-being. That's a better way to say it. Does it actually need to be addressed? And in a lot of cases, the remedy is worse than the cure.

JAMEY: That's interesting.

REIN: Yeah. Another way to think about this is that the world is full of risks and problems of all sorts of shapes and sizes. And if we spent our time just trying to mitigate them, we wouldn't have time for anything else. It is an adaptive, actually, an adaptive strategy to ignore things that don't matter.

VAIDEHI: Yeah, and sometimes you don't actually know if it matters unless you've ignored it and you've seen it come back enough times in enough shapes and forms. Because like, what if it doesn't come back again? What if it's like a blip? Or what if it comes back many times? You're like, "Oh, wait. We can't ignore this." You don't always necessarily know the first time around.

REIN: Think about every error in your error tracker that you are not currently fixing.

[Laughter]

JACOB: Yeah. Not every problem in the world has compounding interest. Some come with 0% interest. Some we develop resilience, too, and eventually we just can absorb them and they are not problems after just enough exposure to them.

REIN: Ackoff tells a story to explain these concepts and it's short, so I'll tell it to you. But then I wanted to maybe use that to transition into, Vaidehi, your other topic: why are good technologists also usually good storytellers, which I am super interested in.

VAIDEHI: Okay. Sure, sounds good.

REIN: The story he tells is a large city in Europe had a problem with their double-decker buses that they use for public transportation. And those buses have a bus driver and a conductor. And the bus driver got paid extra based on how efficiently they could keep up with the bus schedule and the conductor got paid extra based on how efficiently they could collect fares. And so, the conductor was also in charge of letting the bus driver know when they could move away from the stop. And what was happening is during peak hours, the conductor was just letting people onto the bus and assuming they could collect fares after the bus got going. And then this caused lots of problems because then the bus driver would start moving, but then the passengers would move around and then it was a huge problem. So, the management first tried to absolve by just assuming that the problem would go away on its own. This didn't happen. Then they tried to resolve this problem by proposing to retract the incentive, stop paying them extra to do the things. They were not happy with this solution. So management wasn't willing to increase their wages to offset the lost incentives. And so, management next spent some time trying to solve the problem by proposing that the driver and the conductor share in a pooled incentive.

JACOB: How did that go?

REIN: The problem with this is that the drivers and conductors were already in an adversarial relationship. And so, they didn't trust each other. And finally, what Ackoff did is he proposed a modification to the process, which is during peak hours, conductors are put at the stops and they collect fares from people at the stop before they get on the bus. And then they just signal to the bus driver once all the people at the stop are on the bus. And then there was no more problem. 

JACOB: Rather than trying to manipulate sort of an already set human psychology of two groups of people in conflict with one another. Because we can't just flip a switch or change incentives and just get people who have maybe already developed sort of like emotionally hostile relationship with one another, potentially to just sort of stop doing that. Maybe we can just change the circumstances and it's not a problem.

REIN: Martha Acosta calls these paradoxes. There is a paradox there in that system where the thing that the conductor wanted to do to make their job better hurt the bus driver and vice versa. And the only way around that paradox was to remove that situation entirely. The thing I like about this is that we're not talking about this in the context of a story that helps us to sort of understand how this applies in the real world.

VAIDEHI: Yeah, it's interesting. You can sort of use it as a metaphor for how two parts of a system interact with one another and behave with one another, and how if you remove certain factors, how those behaviors change.

REIN: Yeah. 

VAIDEHI: And I bet you could substitute anybody as like the bus driver and the conductor in that scenario. 

REIN: Like, for example, developers and operations people. So in some sense, DevOps was an attempt to dissolve the problem of engineers and SysOps people hating each other.

VAIDEHI: Did they hate each other? I didn't realize that there was a thing. [Laughs] 

REIN: There was some contention because the developer’s job was to break stuff and the SysOps, the operators job was to keep stuff working.

VAIDEHI: Yeah.

REIN: Because 80% of outages come from change. So systems administrators, their job was to prevent change and thus prevent outages. And engineers need to change things to do their jobs.

JAMEY: It's interesting. I feel like I've experienced a similar tension between an engineering team and a sales or marketing team. The tension between particularly, we want to do all this exciting new stuff for our customers versus but we need to make sure the stuff that we have is very stable. I guess just proving the point that we can put anyone in this metaphor and it will be useful.

REIN: Yeah. Gordon Pask defined cybernetics as the art and science of making defensible metaphors. I think a lot about storytelling in terms of metaphors that you can take from one context that apply in the right ways to the context at hand. So, Vaidehi, why do you think that good technologists are usually also good storytellers?

VAIDEHI: I think in order to see the big picture of something, you need to be able to figure out the motivations of different parts of a team or a system, whatever those characters are in the story. And you need to figure out how all of those things fit together to drive a narrative arc. Because if you think about what you just said with that story of the conductor and the bus driver, everything in a system or everything on a team, everything is like moving parts. And the way that they interact together is how things function. And if you can see all of the moving parts as well as the whole, you can sort of figure out the momentum of where something is going. And it's a similar thing with storytelling, with writing, in general. If you're a very good writer, you can understand the motivations of all the characters, but also understand how they all fit together and what you're trying to say with the story, where you're trying to take the reader, how you're trying to hook them in, and why you're trying to keep them reading. There's like this drive, there's this propelling momentum, emotion, something that's driving you forward. And the only way that you can really see that in the big picture is if you know the narrative arc of whatever story you're telling. I think that stories and systems are actually one and the same because it's the same exact pieces of the puzzle that come together.

Another part of it is that if you're a good technologist, you're also probably a good teacher because you can explain your system or your problem or the parts of your framework to somebody else because you can't build everything yourself. You work with other people to do it. And so, you need to be a good storyteller to be able to communicate, like what are the needs of the system? What's happening currently? What do we want to happen? What's the historical context of why it was built this way? And like, here are the things you need to know about why we're doing these things. It's not just like drop a pilot code and be like, make the button turn green. There's a reason. There's a story behind it. And I think that's part of what lends good storytelling and good narratives to good technologists.

REIN: I think that there is another side to this, which is that humans are really wired to think in terms of stories. And so, stories are really powerful ways to connect people with ideas. For example, one of the things that folks in resilience engineering are doing, like the folks on Netflix's core team, which is cloud operations and resilience engineering, is when an incident happens, they're not just reporting the sort of facts of the case, the time line, the "root cause", and so on. They're telling the stories of the people who were there. They're creating a narrative that describes what happens. And when they do that and people read this, they go, "Oh, I can see how I could have been in this situation." And they not only empathize more with the people who were there, they also take more away than they do from just reading this very sort of fact-oriented postmortem report.

VAIDEHI: Yeah.

JACOB: So, what's an example of that sort of texture that they would add? Would it be like I was operating on little sleep and I wasn't focused? What's and example of that?

REIN: So Sidney Dekker talks about it's the investigators job to what he calls get inside the tunnel, which is to say that the people who are operating in the moment have their own limited perspective because they can't see what we can see with hindsight. Investigators that come into these incidents have the full picture of everything that happened in the past. But the people who were there at the moment are only trying to look forward with their current limited perspective. And so, a lot of what telling the story is about is getting people to see what it was like to be there in the room.

JACOB: Yeah, totally.

VAIDEHI: Yeah. Actually, that probably lends itself to making you a better technologist too, because I think a lot of the times, I think all of us are guilty of looking at a system or a project or a team and just picking apart the things that are wrong with it. And I think especially earlier on in your career, once you start understanding the right way of how things should be done or you start developing opinions, basically, you can very easily look at other teams or projects and be like, "Oh, I can't believe they did it like this," or, "This is not the right way to do it." And after you get over that point, you start to realize that none of us were there when things were being built, a lot of the time. And we inherit projects or code bases or databases or whatever, we inherit them, and we were not there when they were being created. We don't know the constraints. We don't know the internal politics, the pressures, the limitations, the budget. We don't know any of those things. And it's very easy to cast judgments, but if you think about what, like what you just mentioned with Netflix, when you put all of the cards on the table and you're like now forced to see, these were the things that were limiting factors. Like this person didn't get enough sleep or we were running out of money or we couldn't upgrade because we didn't have the engineers upgrade the system to this version, whatever. You now start to see, "Oh, I have to be empathetic because I don't know what happened when this was being created."

REIN: Yeah, that's a really good point. It also, I think, helps people find their empathy. I mentor a lot of engineers who are becoming more senior engineers, and a lot of them are getting to the point in their career where they're starting to see systems and they're starting to say, "Oh, I see how this system could be better." And they have these ideas that are good. And then the thing that I try to tell them is, "Okay, the next step that you need to do now is you need to ask yourself, why isn't it already like this? Is it because you're the only smart person who thought of this? Or could there be some other reason?

VAIDEHI: Yeah, and I think that's sort of a defining point where you can look at something and be like, "I accept the things that I was not present for and I don't know what was going on." And, "Okay, this is the reality." How can we deal with what we have now and try to do incremental baby steps to make it better or understand why it can't be better or figure out how to solve it rather than just plopping in and being like, "Oh, here are 16 things you could be doing better, why aren't you doing them better already?" [Chuckles]

JAMEY: I think that sometimes people can get this attitude of like, "These other people are just here messing it up. I wish I could just --" if you want something done right, you have to do it yourself kind of mentality. And obviously, I think that's not true. But I also think that having been in that situation, my first ever tech job that I ever was writing code for, I was the only engineer at this tiny startup I got hired off of Craigslist. It's this little local thing. But I was the only person working on the project. I worked on a project for a couple of years. And I got very used to like, "Oh, if there's an error in the source code, it's just me." There's no one else to blame for it. It's just what I wrote a year ago is bad. And I think that that isn't a great situation in which to work, so I don't think that that's better for sure than working with a team of people collaboratively. But I also think that I kind of gained some empathy from that, because whenever there's that instinct to get blame and see who did this, which I do think is like an instinct even I have sometimes, but I find in my brain that it's not helpful. And I think part of the reason is because it takes me back to this time where the get blame was always just me.

And even now, it is sometimes still me, like, "Look, I did this three years ago. What was I thinking?" And so maybe it's a little bit easier to be kind to yourself. Maybe that's not true for everyone because some people are very harsh critics to themselves, but I find it easier to be like, "Well, I did write this and it's bad, but I didn't know what I was doing. I was brand new and I've gotten better since then." But then it's like, "Oh, but also if someone else wrote this three years ago, they've also gotten better since then." And we're all in the same kind of cycle of writing code and improving over time. And that makes it very clear to me, I think.

REIN: Yeah. Gerald Weinberg has a saying that I think about a lot, which is things are the way they are because they got that way.

VAIDEHI: [Laughs]

JAMEY: I love that.

JACOB: [Laughs]

REIN: When I think about it, I think these systems that we're interacting with didn't spring forth fully formed from the mind of the principal and the founding engineer. The things that exist today are the way they are because a bunch of people had to forge a path through the jungle to get here. 

VAIDEHI: Yeah.

JACOB: I wanted to go back to this concept of [inaudible] and writing up a more nuanced accounting of what happened and putting the reader inside a tunnel of when the incident happened. I think a lot about how I've kind of internalized that as a technologist, incorrect assumptions are such a cardinal sin that basically I should never speak of them. And any incorrect assumption I made is so irrelevant and that it's not an excuse, basically. And I just had an experience just yesterday at work where I accidentally deployed something to our production environment instead of our staging environment, because there were two buttons right next to each other. I clicked the wrong button and I didn't realize that I clicked it. And the more I think about it, the more I didn't say anything at the time because it was just my fault. But as I think about it, the fact that I made an incorrect assumption and pressed the wrong thing is pretty darn relevant. Because then we can ask ourselves, "If I made that mental error, someone else probably could have made it, too." And then maybe there's a question of like, "How do we make that less likely to happen?"

VAIDEHI: Yeah, totally.

REIN: This is where the studies of ergonomics and human factors came from, this idea that actually know the environment as someone has put in matters. The complex systems are highly context dependent. The analogy that I like comes from Herbert Simon, who is a Nobel winning economist and who had a metaphor of an ant in the jungle. So when you look at the path, an ant traverses through the jungle as it climbs up and down a log and looks for food and all these things. If you just look at the geometry of that path, it looks very complex. But ants don't seem to be complex creatures. They have very small brains. And so, the question that naturally arises is where did the complexity come from if the ant isn't complex? Herbert Simon's solution to this problem, which I think was exactly wrong, is that you can just ignore all the complexity as an externality and focus on the simplicity of the ant's brain. And the alternative solution, which comes from extended cognition, is actually the environment that we're operating in changes the way we think. It changes the affordances that are available to us. It changes the decisions that we make. It changes even what options we consider when making decisions. And so, you can't separate the way a person performs from the environment they're performing in.

VAIDEHI: Yeah, and there's so much built-in context to that, too. I think that sort of ties it back again to empathy in that you don't know what that ant -- where the ant I guess is the engineer [chuckles] -- but you don't know what they were experiencing as they were traversing through the jungle. There were reasons that they made the choices that they did. Maybe a log fell in front of them and they couldn't cross the path easily. I don't know. It's so important to not decouple those things, even though I think we completely strip out the context sometimes from the actual problem because we just see it for what it is and we're forgetting that because we can't see the context because we weren't there, we don't remember that it is a big factor.

REIN: This is the challenge of Hindsight Bias. Our perspective is so much different because we can see into the past and they can't see into the future. 

VAIDEHI: Yeah.

REIN: One of the things that safety differently focuses on is this idea that people don't go to work to get injured. No one wakes up in the morning thinking, "I want to go to the hospital today." And so, when you want to understand how that accident happens, you have to look at it from the perspective of workers who were doing their best to do their jobs. And you have to make sense of what happened in that frame, if you want to make sense of it at all.

JACOB: Right. Does this play into -- I think that this discussion has been had many times on this podcast of the concept of blameless retrospectives and then the sort of competing argument of somebody, like professionals should be responsible for their work. I think you you've spoken about this before, Rein.

REIN: Yeah, accountability is challenging. Figuring out the boundary between people being responsible for their work and blame is difficult.

JACOB: Obviously, there has to be some way to find when people are either incompetent, are not qualified for their position they're in, they don't have the resources to do their best work. There has to be some way to find that. With that said, I also completely agree when Rein said people show up to do their best. But there has to be some way to find out when the best is not good enough.

REIN: The thing is if someone is somehow not competent to do the job they're being told to do, why are they being told to do that job? How did they get into the position where they have to perform in a way they're not capable of performing?

JACOB: Yeah.

REIN: And how do you actually -- so this is an epistemic problem -- how do you know the difference between someone who isn't capable in an environment in which the challenges are too great for them to do their work? 

VAIDEHI: I guess you have to change the environment and make sure you've given them a supportive environment, or remove some of the factors that are making it difficult, because that's sort of, I feel like, the first step. Because if we're just talking about the ant and the forest scenario, remove some of the logs, make the path a little bit more straight instead of curving. Try to support them as much as you can. And once you've removed enough logs or I don't know what even enough logs would be like, once you've created the ideal supportive environment and they're still not at that point, I guess sometimes, it just doesn't work out.  Like that forest is just not the right place for that ant.

REIN: You are describing what the job of a manager ought to be, is how do I construct an environment in which people can perform in the ways I want them to perform? And one of the things that I say to managers a lot is if you want to hold someone accountable, start with yourself.

VAIDEHI: Yeah, that's very true.

JAMEY: We're talking now about what the role of a good manager is. But I'm not a manager. Maybe a lot of people aren't managers. I wonder if any of us have any suggestions on how you can try to create that kind of environment without necessarily being a manager. One of the things we're maybe going to talk about in this episode I know is mentorship and I know I've been in the position where I'm trying to kind of create that space for someone to succeed as a mentor, but not as a manager. And I wonder how that's different and what your experiences have been trying to do that.

VAIDEHI: I think it's interesting because the ant in the forest metaphor image that I have from earlier in this discussion still seems to sort of feel like the right metaphor for this, in that if you're trying to help somebody level up or be their best on the team or start producing and contributing as quickly as they can, I feel like part of your role is to move some of the logs out of the way, in that they should feel like they have somebody that they can ask questions to and  they should feel like they don't need to spin their wheels, that they can ping somebody for help or have somebody to pair with. And I think a lot of it, though, is like you want to find that balance between making it easier, but also giving them the environment to feel like they can learn without this pressure of trying to get it done versus trying to learn. I feel that's something I have struggled with as a mentor. I bet there's like a parallel for managers as well. But it's a little bit tricky because you want to support them and make it easier. But you also don't want to make it so easy that they don't know how to navigate it on their own when you're not there, if that makes any sense.

REIN: Yeah. I would say that -- Jamey, you were saying, what if your manager doesn't get it, what then? When you think about what even is the job of a manager, this is something that I think management training in tech is so bad, that it's hard to know for certain. But I think it can be expressed pretty simply, at least from a systems thinking perspective as the job of the manager is to act on the system as a whole to get better outcomes. And so the system as a whole doesn't just mean that you're managing people. It also means that you're managing processes. It also means that you're managing tools. It means that you're managing everything that's in the system, that's in your scope of control. And the thing is, if the manager is often the best position person to take on this responsibility because they have that perspective of the system, they have the authority to make a lot of these changes. But the manager is still just one person in the system and other people have a lot of power, too, especially calling back to our last episode, if the people who want to see these changes happen get together and act collectively.

JAMEY: Yes, I think that people use the phrase managing up sometimes. And I find the phrase kind of difficult. I think the idea behind it is sound, like you don't have to feel like you have no say in your organization or your team or whatever just because of your title in the "hierarchy" of your company or whatever. I think that that's a valuable way to think about things. But I think that the phrase managing up trips me up because I'm like, "I'm not a manager. I don't have those skills or that's not part of my job." But I think that essentially, trying to create a space for yourself and your colleagues to do good work is everyone's job or at least in everyone's best interest, if that makes sense.

REIN: I think it's easy for sort of line workers, line engineers, like people on the team whose supposed job is just to write code, to have a sort of narrow view of their ability to affect change. If you look at the whole scope of a software development team and you just take the development lifecycle where ideas come in on the left and ship production systems go out on the right. A lot of engineers think that their responsibility is this slice in the middle, which is I write the code and then I code review the code. But actually, that doesn't have to be the case. If you're not happy with what's happening to your code after it goes into production or you're not happy with the way ideas are turned into stories, you can do stuff there, too. It's not illegal. 

JAMEY: It's not illegal to care about your own work?

VAIDEHI: [Laughs]

REIN: Yeah, I think that -- 

JAMEY: Are you sure?

REIN: It depends on which team you work for.

JAMEY: I was just teasing. I'm sorry. 

REIN: But it's definitely possible for engineers to have an impact that is outside of sort of their narrow scope of focus.

JAMEY: Totally.

VAIDEHI: Sort of tying this all back to where we started earlier with mentorship, something I'm curious about is like, if you can have a great impact with mentorship, what does that really look like? And what I mean by this is like, what is effective mentorship? What is that impact? What should you be striving towards? And part of the reason this is like front of mind for me these days is that I have been doing a lot of mentoring in my role at my current company, at my previous company. And it sort of made me think a lot about what that actually should be and what it looks like, and when I know that I'm doing a good job and when I know that something needs to change. And how much of the burden of learning is the mentor's burden to bear versus the mentee's? And how do you level up folks? Because when you're in the position of being the mentor, you know where they are, you know where you want them to be. And then you're like, "Okay, how do I bridge this gap?" I kind of see some stepping stones, but I don't exactly know how to get this person there because each person is different. And you remember going through it yourself. But now you are on the other side and you want to sort of bring these folks along. I think about this a lot these days. And I'm curious what you all have to say about it, given your experiences as mentors, mentees, in whatever context.

REIN: Well, I want to know what you think a good mentor does.

VAIDEHI: That's a good question. I feel like the definition is changing for me pretty frequently. But I guess at the crux of it, I feel like a good mentor should be supportive and sort of point you in the right direction, but should also give you the freedom and the pain of figuring out yourself. Because I think a lot of learning is like a struggle. And mentorship is not just like, "Let me just give you the answer. Let me just do it for you. Let me just send you the link of how to do it or copy paste this." It's like, "Okay, this is the general path you should be taking." And I think it takes a lot of restraint as a mentor to do that. But then at the same time, you don't just also want to be like, "Try this." And then, "Good luck." You also want to support them and be like, "Okay. Have you checked your assumption on this? Have you looked into this feature or this syntax?" There's like this balance of support and flexibility. And I think a good mentor knows what that balance is based on the person they're working with, because I think it also changes, because I've noticed no two mentees are the same. So you sort of have to adapt to how they learn and how they respond to feedback and criticism and encouragement.

REIN: I agree with all of it. One of the things that I've learned as a mentor is that a lot of my biggest impact doesn't come from what I try to teach or impart, but how I act as a mentor. I find that people that I mentor model a lot of that in addition to the specific stuff I try to help them with.

VAIDEHI: When you say how you act, do you mean like the way you carry yourself or the way you think about things? What are the things that you see people mimicking or like carrying on?

REIN: Yeah, I see both of those. I see how I approach problems. I see there's, I think, a tendency to focus on the content of the message rather than how it's being shared. And the mentee is learning about both of those things at the same time. So you could be consciously aware that you're teaching them a certain thing. But what you're also teaching them at the same time is how to approach learning, for example.

VAIDEHI: Yeah. 

JAMEY: I agree with everything that both of you said. And I also think I want to add that, as my experience as a mentor, I'm like an underrepresented person in tech, and I tend to mentor other people who are also from underrepresented groups in tech. And so one other thing that I consider a vital part of my job as a mentor is to advocate for someone. I feel lucky in how my career has gone. I've put in a lot of hard work, but I also feel like I've been lucky and I've had people advocating for me. And so, it feels like part of my responsibility is to pass that on to new people. And I think that that's kind of a twofold thing. Partially in helping folks navigate this space as an underrepresented person, which you do kind of have to be thoughtful about in some ways, and also just helping them gain confidence in that way, and also pushing for them. I was mentoring someone at one of my old jobs who, Vaidehi, you talked about getting someone to the point that you want them to be where they can advance. And she was at the point where I felt like she had advanced and I was really proud of her. And I felt like she had leveled up. But she wasn't getting any recognition for that from the rest of the team. And so, I felt like it was my job to be like, "Look, she's really done these things that we were hoping that she would achieve. You need to recognize that, and she deserves to be rewarded, I guess, for that." And basically, I was like, "You need to promote her. She deserves to be promoted. She's at that point." I've gotten her to the point where I think she deserves that. And now all I can do is put pressure on other people to kind of follow through with that. But I consider that totally just as vital of a part of my mentor relationship with her, if that makes sense.

VAIDEHI: Yeah, totally. I think you're totally right. That is such a big part of it. It's like once they get to that point, half of it is also recognizing it in whatever way, shape, or form that should be recognized.

REIN: [Inaudible] described as the difference between mentoring and sponsoring. So I think there's research that shows, for example, that men are sponsored more, but women are mentored more. Sponsorship is actually being their advocate for specific things that advance their career, like leading up this project or getting this promotion or being in this room when this meeting happens or whatever it is. And like Jamey is pointing out, both of these things are important. And it's also important to be aware that there are gender biases and other biases that affect who gets to be the recipient of sponsorship and who is only mentored. Actually, if you have a manager and you do one-on-ones with them, one thing I hope they ask you is, "What can I do better as your manager?" And one thing you could say is that, "I would like it if you would sponsor me more," and then you can explain what that means if you need to. That is a thing that can work depending on your relationship with your manager.

VAIDEHI: Another part of being a good mentor or being good sponsor is making sure that the channels of communication are open because when you just said you should ask for sponsorship, I think it's so important for the person who is being mentored -- I know it's really hard to do this -- but it's important to ask for what you need too. I think a lot of the times, I'm not 100% sure if I'm being as effective as I could be as a mentor. And I sometimes find myself wishing my mentee to just tell me, "This is what I need from you." And so part of it is, as the mentor, your job is to open up the channels of communication to make them feel like they can say that. But then if you're in the position of being a mentee and you feel comfortable, you should definitely voice what you need because sometimes your mentor, maybe they just don't realize that you need something and they're more than happy to provide it.

JAMEY: I think trust is a huge factor in a mentor relationship. And I think that is one reason that that is true. You have to have this trust to be like, "I feel safe being honest with you and asking for what I need in that way. And we have that kind of trust." I think that there's a lot of trust when it comes to learning new things and being perceived as vulnerable when you're learning things and you don't know them yet. I think there's trust in advocacy, too. Like one of the things that I found in the story that I was just telling is that I was like, "I want to advocate for you to the higher ups in our company. Do you feel comfortable with that?" I don't want to go behind someone's back and say things that they're not comfortable with. And so there's that trust too of like, "Yes, I trust you to speak on my behalf in a way that will represent me well." And so there's a lot of trust in all of those aspects, I think.

REIN: If you're trying to be a sponsor, here is a thing that you should do. You should say, "Hey, I was thinking that you would be good for X. Is that something you're interested in?"

VAIDEHI: Yeah. And probably the same goes with mentorship. Like, "Hey, I'm thinking that we're trying to get you to this point. Does that sound good? And do you want to work with me to get there?" I think that's especially true for when you're trying to level up. It's hard to know if you were somebody who is on their first dev job and maybe more entry level and you're like, "Okay, I want to get to this point where I can work independently. I don't know what that means or what that looks like or how to get there." And so part of it is working together with your mentor to make sure that you're both on the same page about what that even looks like and defining concrete task for it. And I think it's the same thing with sponsorship, where it's like, "Okay. This is what this looks like. And the way that we're going to get you there is by making sure you're in this meeting and making sure that you have responsibility over these tests." Sometimes setting those clear definitions just needs a conversation. But a lot of the times, that conversation doesn't happen.

REIN: A lot of mentoring relationships are informal, I think, and it can be really good for the mentor to try to be a bit more explicit about these things, like you're saying. One of the things that can be really good is for the mentor to ask the mentee some questions to sort of start an official relationship. Like, "What are you looking forward to in this relationship?" "What do you think are your strengths?" "What areas would you like to improve in?" Even questions like, "What motivates you?" "What stresses you?" "How do you relax?" A lot of these things you'll find also in one-on-one guides. Lara Hogan has some great stuff on this. But actually doing this explicitly is really helpful in sort of foundational phase of the mentor-mentee relationship.

JAMEY: I agree. I think it's powerful, in fact.

JACOB: Yeah.

REIN: Yeah.

JAMEY: This is not a tech story, but I actually do tarot readings. And I apprenticed under a teacher for a while and it was like a really special kind of apprentice relationship that we had. But it was kind of interesting when it started, because she was already teaching me. I was attending her classes and we were talking outside of class and I was learning a lot from her. But then when we were like, "Okay, I'm going to do this apprenticeship," we discussed like, "What does that mean? Why is it different than what I'm doing now?" And it turned out that it wasn't hugely different from what we were already doing, other than the way that we were intentional about it. And we started being much more intentional about setting goals. "Here are the things we want to talk about." And it made it feel more real and it made it feel more structured in a way that was really good for me. And it also brought us kind of closer together as people in a way that I wasn't necessarily expecting, but it was really cool.

REIN: Yeah. Couldn't agree more. There are all sorts of things that you can talk about here. How much time do you want to commit to this relationship? What is your learning style? How do you want these meetings to go? What sort of discussion format should we use? How can we measure your progress? What would success look like to you? All of these things are super helpful.

VAIDEHI: This conversation is making me realize that I should set more concrete goals for my current mentor-mentee relationship.

REIN: I think that these informal relationships are super valid. There can be good reasons to make the relationship more formal.

JAMEY: This has been a really great conversation, but we're getting about to that time near the end of the show where we do our reflections. Our reflections are kind of something that really struck us, something that we want to think more about, maybe some sort of call to action and something that we want to take away from the show. So I'll start with mine.

I was thinking a lot about what we were talking about at the beginning of the show, about learning and how we do learning. And this idea of kind of incremental learning, just biting off small chunks, not beating ourselves up about feeling like we're bouncing off it or not understanding it and maybe skimming over some of the things that we don't understand to continue to get to the next thing. And I really appreciate all of those ideas, because it's something that I struggle with. Kind of incremental progress and anything is something that's hard for me. I get this feeling like I have to complete it or master it or whatever, all right now. And if I'm not doing that, then I'm failing at it. And it's something that's been on my mind, particularly lately. We did such a good job not talking about the lockdown and stuff this entire episode and I'm going to ruin it with one minute left.

[Giggle]

JAMEY: But I've been really struggling with kind of having focus and trying to get stuff done while I'm in quarantine and feeling frazzled and feeling like I'm not accomplishing things. And so, it's had this idea of incremental progress really on my mind. And so, I really liked the way that we talked about the method of learning in that kind of context of it's not a waste of time to just do a little or it's not a waste of time to think about it, but not quite get it yet. I think that's really comforting for me. And I'm going to try and keep that in mind and let it inform the things I'm working on and learning about and everything that I'm kind of doing at this point in time.

REIN: I think my reflection is that a lot of the stuff we've been talking about throughout this episode has been what are sometimes called soft skills, interpersonal relationships and whatnot. But they're actually very hard and they're also extremely technical skills. And they're also areas where we often aren't even aware that we're performing. Like, when I'm writing code, I know I'm performing. I know I'm doing my job. When I'm having a Zoom chat with my coworker, who is also my friend, I'm not aware that I'm actually performing. I'm not aware that I am having an impact. And so, this combination of the skills that I don't even know I can develop and I don't even know that I'm performing a skill, makes it really hard for me to get better at this stuff. But it's also super important to get better at this stuff because it matters.

VAIDEHI: I totally agree with that. And I think I had a similar take away, which is that it's just so hard to measure and quantify this stuff. And almost bringing it back to the beginning when we were talking about learning and papers, I found it really hard to just quantify whether I understood what was being conveyed in a technical paper or not. And when you sort of think about like, "Am I being an effective mentor? Is my mentee feeling supported? Are we really able to calibrate and pragmatically think about these things?" I think the answer is like, "Not necessarily." And I've sort of come away from this conversation with some ideas on how we could be more empathetic and more considerate of somebody in a different position. We sort of talked about that with those postmortems where you tell a story out of the people who were present, which not everybody else could necessarily understand, but hopefully we can bring them a little bit closer to empathizing with it. And I really like the idea of finding alternate ways to create concrete steps and goals for these things that are otherwise really intangible. And it's probably really hard for us as engineers because so much of our job is binary, like it works or it doesn't. The page loads or it doesn't. And you can measure your success pretty well. But I think it is much harder to do that with these things. And I think for me, on a personal level, learning is something that's also really hard to measure. And I like that we took this conversation from something that's super personal to me and expanded it to something that applies to probably any single person on an engineering team, regardless of the context.

REIN: Yeah. Cool.

JACOB: I am really thinking about the concept of describing an incident or what went wrong in terms of everything that was understood at the time and how that can sometimes be very limited and how that's different from everything that could have been understood, like trying to really describe like, "This is what I knew. This is what I was thinking about. This is what I assumed." And how that shouldn't be a bad thing to say, "I understood the small thing, even though this bigger thing was true, and technically I could have known it in the ideal world." So, I'm going to be thinking about how to make a safe environment where people can just sort of talk about, like, "This is what I knew, even though it wasn't true." 

REIN: Yeah, that's really good. The thing you want is psychological safety, but that's not very helpful because psychological safety is just a trailing indicator that you're doing a bunch of stuff right.

JAMEY: Thank you again, Vaidehi, for coming on. It's really great. We really appreciated your time and your expertise.

VAIDEHI: Thank you so much for having me. I had a lot of fun. It was a great conversation.

REIN: Yeah, it was good. I really enjoyed it. Thank you so much.

If you enjoyed this conversation and want to have other similar conversations with other people who also enjoyed this conversation, you can join our Slack. The easiest way to do this would be to donate any amount to our Patreon, which is Patreon.com/GreaterThanCode. Also, while we're all dealing with this stuff, if you're trying to find a job, we have jobs channel in our Slack that you can join and you don't need to give us any money. Just DM one of the co-hosts or some other such thing, and we will invite you.

JAMEY: Even if you're not looking for a job, if you need a little bit of community in this time and you can't afford to donate to us, feel free, we will give you an invite. If you can afford it, we'd really appreciate it. We have costs associated with the show. But it's more important to us right now to kind of foster a community in this way. So, let us know.