Algorithms + Data Structures = Programs - Episode 30: Google, Interviews, Leadership & More (Part 2)

Episode Date: June 18, 2021

In this episode, Conor and Bryce talk to Chandler and Patricia. Chandler finishes telling us about his career path leading up to Google and then we talk about interviewing, leadership and much more.About the Guests:Chandler Carruth leads the C++, Clang, and LLVM teams at Google, building a better language with better diagnostics, tools, compilers, optimizers, etc. Previously, he worked on several pieces of Google’s distributed build system. He makes guest appearances helping to maintain a few core C++ libraries across Google’s codebase, and is active in the LLVM and Clang open source communities. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. He is regularly found drinking Cherry Coke Zero in the daytime and pontificating over a single malt scotch in the evening.Patricia Aas is a C++ programmer with a “thing for building browsers”. She works for a company she co-founded called TurtleSec where she teaches courses in Secure Coding in C++ and does consulting and contracting. She has been a professional programmer for 16 years, and started off her career working on the original Opera browser. Since then she has made embedded products at Cisco and another browser at Vivaldi. When she has time she works on her own open source (pre-alpha) Chromium/Blink+Qt based browser called TurtleBrowser.Date Recorded: 2021-06-05Date Released: 2021-06-18ADSP Episode 29: From Papa John’s to Google (Part 1)WgetLLVMHow Do You Decide Whether an Individual Contributor (IC) or Engineering Manager Role is Right for You?GCC CompilerClang CompilerISO C++COBOLIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

I just want to clarify for our audience. Why? Why? I think we can just leave that where it is. When Connor says he's not in the closet right now, he's referring to the closet that he records in. Bryce, you're not actually helping? I mean... Yeah. Welcome to ADSP, the podcast, episode 30, recorded on June 5th, 2021. My name is Connor, and today with my co-host Bryce, we continue our interview with Chandler Carruth and Patricia Oss, which we started in episode 29.

Chandler finishes telling us about his path to Google, and then we dive into topics including interviewing, leadership, and so much more. If you haven't listened to episode 29 already, I highly recommend you pause this, listen to episode 29 first, and come back. And then I get the two other job interviews that I've ever really had. And it was Wednesday I interviewed at google and thursday interviewed at uh apple and i failed both interviews um wait what also what was the second one the first one was the uh you didn't get your own job oh oh the second one was uh i interviewed for uh a startup in uh uh out that was spun out of the university uh that i did internships with i interviewed with them um but it wasn't much of an interview because i'd actually done an internship with them

and and so like they actually they actually were going to offer to hire me um um but i didn't really want to work in north carolina for the rest of my life and so i i wasn't super motivated to to take that particular offer okay so wait a second. So you interviewed at Google and Apple, and you were rejected by both? I wasn't rejected. I just bombed the interviews. Oh. You know what? You are like, I don't know, you're like dipped in luck or something.

I don't know what happened to your life. Well, it's funny because both Chandler and I got our like first tech job through somebody, through DMing somebody on IRC. Yeah. I couldn't have been more lucky. So I do my interviews and the interviews are interesting here. So in the Google interviews, I got a really good interview that I didn't do very well on, but I also didn't crater. And it was actually a very good interview question. I ask it myself now, so I'm not going to go into that one too much. But it actually made me think about kind of challenging technical problems and explain concepts in a useful way. It thus thereby demonstrated how little professional software development experience I had. Zero. So, but it also demonstrated that I could think critically and such. That was probably my

strongest performance. There was another one that was a terrible interview question that was basically a brain teaser about how floating point works. And I did really well on that one because I happened to have struggled with floating point because I happened to have worked on LLVM. But like, it's a terrible interview question that like it didn't, it shouldn't have been a significant factor. The other interview question that I remember that I've talked about publicly as just like one of my least favorite interview questions was like, it was the last interview of the day at google um and i you have to understand like this interview process was horrible for me so i had one outfit that was like interview level professional uh because i was a graduate student paying for things from credit cards right and uh that outfit of course wasn't what i was going to

wear at apple because at apple it matters what you look like when you interview at Apple. And so, for my Google interview, I showed up in jeans and my thesis hoodie. Isn't that like what they expect now? What is a thesis hoodie? Like the hoodie I'd been wearing and hadn't had a chance to launder

the college of the thesis. That's what I thought. By thesis, I thought you meant you got like a, you know, I defended my thesis. No, no, no, no. I misunderstood. No, no, no. It's like I'm sitting kind of

kind of punch drunk from having defended a thesis on Monday, printed it, submitted it on Tuesday, got on a plane, flown across the country, slept after flying across the country for one night got up and like arrived at google's campus at 9 a.m and i'm sitting in a lobby surrounded by people in suits with portfolios like looking sharp like for an interview in my jeans and my thesis like hoodie it was it was something else so the last interviewer shows up and he asks and he like shows up he's like i want you to implement wget like the tool just implement it on the whiteboard go go i looked at just like

it's like i was like i've i've never done networking network programming in my life like i literally have not written socket open paren once i didn't like just it just never came up it was not a particular focus of mine in school i just like all the code i'd written i was all around compilers and video game graphics and not around like networking and he looks at me it's like i mean oh okay but like fine fine just walk me through how this like like like you can use pseudocode that's fine i don't care if you know any network like but like walk me through like what you would need to implement wget like you know send an http request and get a response and i looked him like like i do not know anything about

the like http i don't know the protocol i have no idea what's needed here i don't know how i need who blinks at me and he's like you do know where you're interviewing right yeah i was that was that was basically what i was thinking it's like this is google and and i was like yes but i've worked on like compilers and programming languages it says so on my resume like you shouldn't be surprised by this i didn't actually like claim anything else on my resume um and and so he kind of like like, and so, like, he's like, okay, well, diagram what you know. And I basically, like, said, like, well, you're going to send a request to the server, and the server's going to send a response. And he's like, let's talk about your favorite programming language. By the way, folks, that's code for the interview's over, and I'm going to fill the remaining 45 minutes.

Oh, dear. Yeah, my interview didn't go well would you have hired you? probably not good question honestly probably not so I can tell you why I got hired it was because of my open source work

I was about to say that I'm almost certain that the reason that they hired Chandler and the reason that they went out of their way to set up an interview with him had nothing to do with how he did an interview. Like I think I may have told this story in the past. And if not, I apologize in advance to my team member who I'm about to embarrass, but not by name. But I had somebody who approached me at CPPCon a few years ago and said, hey, I think I want to come work at your team. And I told her, send me your resume. And she did. And this isn't somebody that I'd known previously.

We'd met at the conference that year. I talked a little bit, thought she was impressive. She sent me her resume and I looked at her resume and her GitHub for about five minutes. And I was like, yeah, I have all the information that I need now. And there will be interviews that will happen. But like, I am deciding here at this spot, five minutes after looking at this person's resume, that I am going to hire this person.

And we did hire and it worked out wonderfully. And, you know, for sometimes you just know it's somebody that has, you know, a prolific open source background. And it's just like, you want that person. And so because the person who got me to send the resume in in the first place knew about my work in LLPM and he knew how the hiring process at Google worked. And so he made sure that in addition to my interviews, they also were aware of the open source work. And my understanding is that this was still not especially impressive. And I've looked at my open source work from then, and it was not especially impressive.

Maybe it was impressive for its time. No. No, it's about potential, though though you know like i i i think this is like one of my skill sets is like being able to like like recognize untapped potential or whatnot like sometimes it's not about what the person's done but it's about what potential you see and what they've done like maybe maybe somebody hasn't done a lot but if they're if they're like very early stage career and at this point in theler's life he would have been very early stage and so you you know and honestly my guess is because this was somebody that you knew chandler from irc right

that it was not somebody that was like new from irc is it somebody that you'd interacted with previously only on irc i've never met them but but it was probably less about the open source contributions that you made and was probably more about how you'd interacted with that person so the sort of questions you'd asked on that irc channel okay okay okay sort of discussion then i have a question because you have like connor you you can you can bow out on this one but but both bryce and ch Chandler have met me in real life. You've interacted with me on various media. And maybe watched me speak.

So would that be, I don't know if you have looked at my GitHub, but would that be sufficient for you to say, I think maybe we should hire her? Yeah. This doesn't compute in a bunch of ways because you're not like super new in your career and just starting out. No. Right? And so there are a whole bunch of other questions that I would want to know about.

And that brings us to the list. And that does segue us over. So I will catch you us to the list. And that does segue us over. So I will catch you up on the list. So the list is basically four stages of your career. And it's a lot around handling conflict. So the junior, I have named them, so you might not agree with the naming of them. But the junior role is a lot about conflicts within the team. So with other team members, but very much at a peer level.

And failures within the team with the project, but something that is very directly to the person. Now I'm interpreting, so you can tell me if I'm... Yeah. The second one I call senior. And that's more about like building consensus as well as looking further than the team, looking towards the customer and towards other teams. And then also, again, dealing with conflict here. And then the one that I had a hard time, so like middle something role, and that's now in vision and and and aligning teams and having more of a broad

multi-team kind of thing but but still pretty hands-on you know it seems to me um and then you know you're in the more of the leadership kind of role tech leadership kind of role uh which is like the fourth one and now you're in influencing higher uh like like the like the xx and and and also looking at at strategy but not only within the company itself but also in the industry and again dealing with with but but i i don't there are a little bit of a conflict there but there it seems not so much dealing with conflict and more like how to to move things yeah would that roughly describe these i think the only thing i want to tweak about that is the the leveling here i'm really the third group is so I

think of this as right, like, junior or like entry level, right, like, like engineering, right. And then the second one is as you know, senior or kind of like, team lead, right, like, like, you know, project lead, that kind of thing. The third one, I think is already really into leadership. And that's, that's why that's why it shifts a lot between the second and the third level here. And the fourth one is not about kind of entering a leadership role, but scaling your leadership, right? And so kind of the scaled up aspects of leadership, when you want to kind of operate at an even broader scope and scale. So one of the things that a lot of people think about or wonder is how you transition from one one stage to the next. And so where do you consider yourself to be in these four stages today?

Oh, gosh, I don't know. Is it also worth mentioning? I'm not sure. We can ignore this. I can cut it out even. But at most companies, too, there is two different tracks that I think. There's the management track and the IC track. IC standing for individual contributor.

Is that worth mentioning here? I think it is. But I think there's also a common misperception here, which is that there's almost always a third track. Some companies, the management and leadership are combined, but that's not always the case. So I think that you should think separately about solely an individual contributor, leadership, and management? I mean, we can imagine a bunch of stuff. I can't speak to any other companies. I've only, like, you've heard the story now of how I got my job at Google. That was the first real job I got, so I can't really speak to anything outside of Google. But at Google, at least, there are two

tracks, right? You're either on kind of the technical track or the management track. And they both go up, and you can become a leader on either track. And so they both have the kind of growth potential here. But they do change your focus. And there's plenty of overlap between them too they're not they're not like rigidly separated tracks they're really about you know what your primary focus is as like in your job and in your career okay so you are on a technical track i assume so i haven't been to be on the technical track on uh at google and i i don't know i mean i i i struggle to be kind of i don't of, I don't want to be, Connor, you might have to cut this out, I don't know how to say where I am. Like, on one hand, I think I don't have a clue about any of this stuff.

On the other hand, at this point at Google, I'm pretty solidly in, you know, operating in the fourth bucket here. I've been very, I was very lucky to get into Google. But one of the consequences is that kind of coming in at Google as like the bottom end and just barely getting past the interviews kind of shook my world a bit. And I got kind of weirdly ambitious all of a sudden. Like ambitious like career- wise or ambitious like?

Yes. Oh, okay. But you say you're on the technical track at Google Chandler, but you do have direct reports, right? Oh yeah. So I'm on the technical track at Google, but I actually manage a large organization at this point. It's like I have over 60 people in my organization and I'm responsible for not just

managing people, but managing managers. Yeah. See, and it's a bit, I think it really depends from like company to company. Like I'm in a, you know, a leadership role. I don't, I mean, I spend very little of my time these days at NVIDIA writing code, but I don't have direct reports. And that's just sort of the, I had i had opportunities to go into a a track where i would have direct reports but it i did not think that that would allow me to rise as high um and in nvidia there's you know there's a role where you can be a leader of people without you know being without actually managing any people so i think it really depends from company to company. So what is that role called? Like, is that like a principal engineer or what is this?

So at NVIDIA, usually that term is associated with like architect. But also NVIDIA is not a company that has a very rigid hierarchy. So titles aren't really that significant at NVIDIA. You get to shape your own role. So it was really just that at some point I decided that the way for me to get more things done was to spend less of my time as an individual contributor, more of my time sort of as a leader of people. But for what it's worth, while I have reports that's not universal, it's not even all that common for people on the technical ladder. And I'm probably going to be having fewer reports over time, not more. But this is kind of like, you know, it's come and gone.

The group I was in had a real need for someone to kind of step up and do kind of higher level organizational management. And so I stepped into the role because there was a need for that. But in some ways, my goal has also been to largely kind of, you know, replace myself in that role over time. I'm hopeful to go back even more towards, I'm about as far towards the kind of management and organizational leadership as I ever want to get. I'm hoping the pendulum swings back a little bit more towards technical things in the future. Yeah, just, I think it's worth mentioning because for those that aren't, that are listening to this, that aren't at what I would call a technology first company like NVIDIA or Google or, you know, there's a lot of large names, but there's also a lot of smaller

names that are the technology first. I first worked at a financial company that was not technology first. And one of the big draws to wanting to switch to a technology first company is the fact that they have this delineation between tracks. And at a lot of non-technology first companies, there's a single track where for the first few levels, you're technical. But if you want to progress past that level, you have to switch to management. And I, at least at this point in my career, don't really want to be managing people. I want to be solving hard technical problems. And at Technology First companies on the IC track, typically you don't have to have reports if you want to. You can go from your senior engineer to principal engineer and have like a big impact by solving the harder technical problems by mentoring, you know,

younger senior engineers and whatnot. And that's a path that exists at basically every single tech first company, which like for me, someone that wants to like follow that path, at least at this point in my career is like awesome where there's a lot of companies that you hit this sort of like level and then they're like, well, if you want to progress, you got to start managing people. And there's a lot of, I don't want to speak for everyone, but like, at least for myself, I definitely know maybe, maybe at some point I might want to manage folks, but definitely right now I just, I love typing code too much.

When I was at Cisco, they had, they had this idea of a principal engineer and it was actually like something that because we're like we have like a satellite office thing thing cisco buys company so we had a company cisco body um so but but so i basically found like all of the documentation for this like principal engineer stuff myself and part of that was like um it said basically to become a principal engineer, you kind of had to have already been doing the work. That was like a thing. And the funny thing is that I was at that time doing the work. But but but then I was told when I was like I brought it up that I want to kind of go in that direction. And they told me, no, this is an honorary title. This is like we give people that they've been here for like 15 years then you know they get this title because their hair turned gray

or something that's unfortunate yeah yeah i think anytime you see a company that has um uh a strong association between seniority and rank, that's usually a little bit of a red flag. I mean, it's obviously, I think it's, you know, it's usually going to be present to some degree at some company, but that should not be, titles shouldn't be honorary, right? Titles shouldn't be something that you reserve for the folks that have been there for 15 years um so but but the reason why i thought about it was because one of the one of the requirements for getting this was that you couldn't have any direct reports and so they gave the title to to uh to someone while i was there and they that that person had to to uh to lose their direct reports to be able to get the title. Interesting.

It was weird to me. That's weird. Yeah, especially if it's honorary. So when I, earlier this year, I switched to sort of a new role at NVIDIA and I had the, there was an opportunity for me to like consider switching over to the management track. But the reason that I didn't was that it sort of unintuitively, Connor was talking about how at some companies you have to manage to get to the next tier of manager and the tier beyond that, I would have to be

managing more people than I thought I would be comfortable with managing in the next five years of my career. Whereas on the technical track, I could be in a role where I was a leader for the size of people that I was comfortable being a leader for, or even more. And there was plenty of room for me to grow, that there were at least two levels above where I was that I could reach for in the next five years without going outside of my comfort zone. And so that's why I decided to stay in the technical track. Okay. So you're both speaking, like both you and Chandler, at least, are talking about this idea of leadership, but separated from management. So you're talking about technological leadership in some way,

and it seems to have, like, that expression seems to have content for you. So what does that mean? I mean, for me, it's about, you know, influencing and, like, setting direction. And this is why you can kind of see this showing up in the kind of questions that I was probing here. It's about establishing a direction and a strategy

and the scope at which you do that. The scope of the problems that are solved by it, the scope of influence you have to deploy to it. What does that mean, though? That sounds very vague. Give me an example. Sure. So an example of this would be your,

I'll take one from my own experience here, right? If we're at Google and we're actually using, you know, GCC, and at the time the compiler is not really meeting Google's needs, right? Actually figuring, realizing that the needs that we have are not for just a better compiler, but for example, for tools built on top of the compiler in order to help our code base scale and our developers kind of deal with the challenges of C++.

It became very clear that we needed a different platform. And so one of the things I had to do was to go around and convince everyone at the company that like, no, we're going to directionally pivot from building on top of GCC to building on top of Clang and LLVM. Not because they're better. At the time, they weren't even better. They were actually worse as a compiler. But because they're going to give us the leverage we need.

We're going to be able to build the tools we need to build on top of them. And so as a direction, we have to kind of pivot the entire company's direction so that we can build those tools. So how do you do that? Largely, it's about presenting a good argument with good evidence to support it to the right people at the right time. And so you have to be able to get into that room, I guess, to those people. That is one thing. You do have to have access to the people who you need to kind of convince. However, at least at Google, that part is actually probably the easiest part. If you put in enough effort, you can almost certainly talk to anyone at Google that you

need to in order to try and convince them of something. It's very unlikely that you can't find a person that you talk to, even if they're kind of, you know, some layers that you have to work through, right? You can at least find the person at the first layer. And if you can convince them, they're going to make sure you can talk to the person at the next layer of the company. And it's an incremental process, right? This took us, this took probably, I would say, six to seven years to really establish this directional shift at Google fully, right? And there were just a lot of milestones along the way. And there was a lot of, you know, lot of pushing this directional strategy further and further and further at each stage of this. And the surprising thing is that even the thing I've outlined, changing the compiler from one technology stack to a different technology stack because of a different set of use cases that we have, that's actually itself just an incremental step. Everything kind of

decomposes into these kind of incremental components. And so that's actually an incremental step of changing the direction of the strategy for how we write C++ code at Google. And another component of that was Google kind of becoming much more heavily involved in the standardization process and trying to push on the industry and the oh, the leadership means having the vision and then inspiring people to believe in that vision. So I think it's fundamentally about people. somebody to do something, saying, do this because I told you to, and inspiring them to do it because you've convinced them that this is an exciting thing or that this is the right direction to go in or that this is something that they should believe in. And I think that's really what leadership is about. You have to understand the problem that you need to be solving, the business that you're in, what your users need, and then you need to be able to identify

what is the solution to that problem. And then you need to get your people to believe in the problem, to believe in your users, to believe in the business, and to believe that the solution is the right way forward. And I think that my experience may be a bit colored by working so much on community-driven projects and standards committees and volunteer organizations, because when you're in a volunteer organization, you can't just tell people what to do. You have to work with, you know, when people volunteer, they're going to volunteer to do what they want and you can't just give them orders. And so perhaps my experience is a bit colored by that, of, you know, of that, that the only way that I can get people to do things in a lot of contexts is if I can inspire them to do it because I can't just tell them to do it. I want to, I want to let everyone in on a secret. That's always true. So a lot of people think that like

open source or standards committees or other things are different here. I don't think they are. I think this is actually truly common, right? at google we're we're a big company these days right we're a big company so there are plenty of teams and managers who i've seen basically like receive direction like go build this thing over here if the people on that team don't believe believe that this is a good idea it fails every single time with like like there's no i have zero success examples when a group of people a team didn't believe in what they were building but they built a thing that was successful like i have literally zero examples i i have an example but i have an example for like really sad reasons. So because one of the things that I noticed when you are talking about this is that you are never really talking about getting people to listen to you.

Whereas, so my entire career has basically been every room I walk into, I have to prove that I am competent to be in that room so that is like my entire career is is working from like negative 500 the moment I walk through the door and and so so so I so like the shift that I I managed to do inside of Cisco we build these telepresence systems for for conferencing rooms I did a massive amount of research I did like probably like 20 hours of presentations I built prototypes I built an actual like like a like a like a full product with cameras and microphone arrays and a touchscreen, and we had web stuff on it. And it was like, I had to really, because nobody would listen to me, because I was a girl. So the lengths that I had to go to just to get people to listen. And when I went into the room and I said, the way that we're doing things now, it won't work. And getting someone to actually listen to that, it was so hard. when they bought my idea. They called a meeting with 20 male engineers

and they didn't ask me to come. I think you're absolutely right. And I think people like Chandler and I, I think we tend to be loud people who, we have strong opinions and we don't have a problem sharing them. And I think because we're, you know, white guys in tech, that's very accepted, right? That, you know, like if I spend most of my time going into meetings and pitching people on crazy

ideas that nobody believes in yet and trying to convince them to believe in that. And it's easier for me to do that because I know that it's acceptable for me to do that and that I feel confident doing that. But you, Patricia, as a woman in tech, one, you're not going to feel as comfortable doing that because you know that there's a huge bias against you and two it's so much harder for people to listen i would be the one presenting and people would shush me in the meeting i had a guy who was like an executive saying in the meeting who do you think you are and i was like i'm i'm just here answering a question you asked me.

I think there's also, like, it's weird, right? Because one of the things that I've been fairly lucky with is that, you know, certainly I get a foot in the door right but being by looking like everyone's expected image of of random geek helps um but i think it's important for people to realize that um that that helps and it makes a big difference but i actually think the goal and like the challenge is is it's structurally the same it's a difference it's a it's different than magnitude a big difference in magnitude but you still have to convince people to listen to you well the thing is that the thing is in the end

the way the way i won was by proving my point i didn't win by convincing anyone like i i convinced them by by proving the math i i didn't convince them because they believed in me they didn't believe in me at all what i managed to do was to prove by implementing by it because what i was saying was not and no matter how much research and no matter how much i would present nobody would believe me. So the only and this is the reason why I won. And this is also one of the reasons why I think women have to be engineers. Because I won because I could make it. I would have never won if what I came in there was was some kind of like crazy idea. I came in with a product. I could demonstrate it.

What I'm trying to say is that's how everyone ends up winning. At least in the meetings at Google, I certainly have never been able to just convince people. I've had an easier time with it, don't get me wrong. But you always have to to uh i think come in with the product usually usually for me the tide sort of the tide tends to turn like when it's far too late like like like i like i i typically try to convince people of things you know early on um and they only will get on board once it's become inevitable that that's what we're doing. And it's already sort of already happened. But I do think that, yeah, I think what Chandler, what you're saying is right. It's like, yeah, that like oftentimes you're not going to convince people.

You just have to go and find a way to show them. I had one particular project recently where I sort of realized there's no way that I'm going to convince people if I don't just go show them on that. Although it turned out to be wrong. I was able to convince them otherwise um but but it's harder for for I still think that the bar is different for for if you walk into a room and people don't expect you to be competent then then they will treat you differently they will speak to differently but even worse they will not listen to what you're saying i i've been in meetings where i will speak and then then the next person will speak and nobody will ever mention that i said anything and then you know four minutes later a guy will say exactly what i had said

four minutes earlier and then everybody will be oh yeah very good point and i'm like yeah yeah no but it's i i yeah i i had I had a manager go to me and said Patricia you need to be more like because I said that I would people were stealing my work and you know and he was like yeah you have to be more assertive and you have to like like like say I made that and blah blah blah and it's like and and so I was like okay fine because you know that's how all of this process works. It turns it against you. So it's you that's wrong. It's not the system that's wrong.

It's you that's wrong. So I was like, okay, fine. So the next time somebody presented my work as their work, I said, yeah, it's great that you could use the thing that I made to do this. And my boss was furious. Yeah, he was yelling at me. And I was like, I'm sorry, but this was what you told me to do. I'm sorry, I can't win here. It's like, there's no, this is not a game that is winnable.

I mean, I think the only winning move is to, you know, go to a company or an organization where this does not happen. That's the winning move. One thing I have found tends to help here, at least in my experience, is if there's something where I've said it, or I feel like I'm answering the same question multiple times, or I'm explaining something, and people are just not hearing the words, they're just hearing whatever they want in it that is often when i realize okay it is now time for me to write this down in some

document or put it in slides or something um and it sort of sort of to have some sort of paper trail where the next time that it comes up i can just instead, instead of giving the explanation again, I can just point at, I'm not going to get into that right now. Look here. We've already done that. And here's the paper trail. And like, here's the answer to your question. Yeah. I had to do that all the time. There's no way for me to come into it. And that was also when my boss was like, yeah, why do you always bring a PowerPoint presentation to every every meeting and i was like not only do i bring a powerpoint presentation to the meeting i will send it in the invite you nobody can come and tell me that they did not see it or didn't get it and that it's not documented and time stamped i've started in every meeting that I run, I take detailed minutes and I send them out.

And I almost never read the minutes like immediately afterwards. A couple of the people who are on the meeting invites do read them and give feedback. So they are useful in that regard. But the primary reason that I do this is that three or four or five times a year, I get asked for a paper trail on something. And I now have this magical power where I can be like, that happened on this date, on this date, on this date. And we said, you said that, that, and that, and that. And it's just like, end of discussion.

I had a wonderful, like two mentors or bosses, I guess, at some point in my career. And they had a very good, like, motto. They said that the people who write the minutes decide what was said. Yeah. So they said whenever you are in, like, a meeting, especially if it's antagonistic in some way, you make sure you are the ones writing the minutes.

And this is, if you look at the history of the COBOL programming language, which was the first language developed by a committee, that's one of the, and it's, COBOL's a very interesting language because it was developed in the 60s and most of the primary people behind its development were women. Well, how did that come to be? Well, two reasons. One, at that time, being an engineer or a programmer was not, you know, the cool thing. It was all about being a businessman, the business logic. So most of

the technical people involved were women. But two, who took the minutes in those meetings? Who was the one that was running the meetings where they were developing COBOL. It was always the women, the heads of all of the subgroups of the COBOL committee. I think 60 or 70% of them were women. And there is an incredible power in being the person that is running the meeting or that takes the minutes. You get to literally write history. So I i'm just curious should we try and get back to mr cruz we'll pause here and resume part three next week thanks for listening we hope you enjoyed and have a great day