Software development is a team sport and, for this inaugural episode of "Conversations in Software Development", we are very lucky to have a conversation on this subject with Ben Collins-Sussman and Brian "Fitz" Fitzpatrick.
Besides being accomplished software engineers, Ben and Fitz have collaborated on multiple talks and books regarding the social challenges of software development, including the popular O'Reilly book Debugging Teams: Better Productivity through Collaboration and most recently contributed several chapters to the book Software Engineering at Google: Lessons Learned from Programming Over Time.
Software development is a team sport and, for this inaugural episode of "Conversations in Software Development", we are very lucky to have a conversation on this subject with Ben Collins-Sussman and Brian "Fitz" Fitzpatrick.
Besides being accomplished software engineers, Ben and Fitz have collaborated on multiple talks and books regarding the social challenges of software development, including the popular O'Reilly book Debugging Teams: Better Productivity through Collaboration and most recently contributed several chapters to the book Software Engineering at Google: Lessons Learned from Programming Over Time.
Hey everyone. Welcome to the very first episode of conversations in software development. My name is Berhan Sotomayer. I am a senior lecturer in the department of computer science at the university of Chicago, where among many other things I teach a class on software development. In that class, I often invite guest speakers to talk to our students about various aspects of software development. But this year to do the coronavirus virus crisis, uh, holding guest talks on campus was obviously no longer an option. So I decided to make lemonade out of these lemons, uh, and use this as an excuse to launch a podcast on software development that is intended mostly for students. Uh, my main goal with this podcast is in fact to expose students to aspects of software development that they may not get to experience or learn about in a classroom setting. For this inaugural episode. I am very lucky to be joined by Ben Colin Sussman and Brian Fitzpatrick, better known as fits a, besides being accomplished software engineers. Ben and Fitz have collaborated on multiple talks in books regarding the social challenges of software development, including the popular O'Reilly book debugging teams, better productivity through collaboration. And most recently contributed several chapters to the book software engineering at Google, lessons learned from programming over time, which just came out a few weeks ago. Fits and Ben, thank you so much for joining us.
Speaker 2:Hey. Yeah, that's right.
Speaker 1:Very awesome. Before we dive in, could you tell us a little bit about yourselves? Uh, Ben, let's start with you.
Speaker 2:Oh, hi. Uh, so I've been working in software for, I dunno, 25 years ish, uh, right out of school. Um, I, uh, spent years as assist admin and then as a programmer. And then I've spent many years working on open source software with fits, uh, version control systems and then fits in. I, uh, went to Google and we started the Chicago office together. And, uh, at, at Google we worked on developer tools and ads and all kinds of exciting things. It's can tell you more about that these days. I'm working on Google search, which is the, uh, the juicy core of Google. It's a lot of fun, a very interesting, uh, and uh, along the way, you know, as, as we mentioned, Fitz and I learned a lot about software engineering and management and we sort of ended up turning a lot of the, what we learned into talks and books and other things like that. So I'm happy to be here. I should point out, I am also a university of Chicago alum. Uh, I went to school, uh, to the college in the early nineties. There was no computer science program back then. You could just take some CS classes as a, as optional at the time. So I was a math major and I didn't actually take any CS classes. I just sort of taught myself to program is as was common in those days. Right. Fits a lot of us were, a lot of us from our generation were sort of self-taught programmers. That's how things often were in the 90s. And so, uh, uh, for, for those,
Speaker 3:uh, you've, you Chicago folks playing at home? Um, I was actually every summer of college in the early nineties. I was an intern at argon working for a guy named Ian foster, who seemed like a very, uh, upstart professor. Uh, I think it turned out well, so, and there he is. So
Speaker 1:great. Uh, fence. How about you?
Speaker 3:Yeah, I'd like to point out that I did not go to university of Chicago. I went to that other school up in Rogers park called Loyola. Um, but you know, in true as, as Ben said, there wasn't a lot of, you know, a computer weren't a lot of computer science degrees back then. So I got my degree in Latin with a minor in Greek and pottery. Um, so yeah, I have a backup plan. Yeah. I think my mom thought I was going to be homeless. Uh, and so, uh, yeah, I, I, you know, I, I, I initially went to school thinking I was going to be a classics professor and Sienna studied in Rome and worked there for a couple of years. And then I realized like, I, I, I had no desire to be a professor and bless you more Hoffer for being in academia, but, uh, it's hard. It's, yeah. And, uh, you know, after I moved back to the U S from Italy, my little brother came over who was studying engineering at the time, introduced me to Unix and Pearl back in 1994. And that, like, that changed everything. I went from being a sort of, you know, grade a slacker to doing nothing at all and playing video games to just being obsessed with programming. And I, I learned as much about it as I could every moment I had free. And then I got a job as a junior CIS admin at this small local company and eventually worked my way up to, you know, an engineer and engineering manager. Uh, and then got a job at Apple, uh, worked there for a few years. And in my free time I was working on version control with Ben. And then I actually went to work with Ben and some other folks on other friends doing open source software and uh, and saw some version version control. Yup. And then Ben and I went to, we started to Google Brad around the same time working on developer tools. And then, uh, I, I went my way to, to sort of do this data liberation thing, uh, was around data portability. And then later engineering transparency, uh, at Google. And I had a blast and a, about five and a half years ago now, I left Google. I abandoned Ben. Um, Ben likes to remind people that I told him that I was leaving Google when we were doing 80 miles an hour in a car driving to Monterey for an offsite. So I couldn't leave, so he couldn't run away on me. But yeah, so I started this company without Nick Kokona. So who was, owns a linear, one of the best restaurants in the world, uh, doing a bookings, restaurant bookings called talk. And uh, that's what I've been doing for five and a half years, have built a great engineering and I've got a great design team there and, uh, things are just ticking along.
Speaker 1:Great. Uh, so, uh, as you know, uh, I teach a software development class, uh, at the university of Chicago and in that, in that class I schedule a few guest talks from folks in, in, in industry like yourselves. Uh, and I've been lucky to have the both of you come speak to our students in previous offerings of this class. Da. I've always put your talk first on the list of guests talks because working well in a team is essential to doing well in this software development class. And the, the two of you are nearly infinite source of wisdom on how to make software teams, uh, work. Uh, but my, my first question for you is, uh, how hard really is it to make a software team work? I mean, can't you just hire a bunch of genius programmers who just graduated from the best schools in the country, put them in a room and wait for the magic to happen? And for the trucks of money to arrive, thanks to all the amazing software there'll be writing
Speaker 3:if only it was that easy. Uh, you know, I, I really think that there's so much to look for. Like, I guess I'll back up a second. When Ben and I first started at Google, we worked for this amazing person named bill Corrine, who is a senior VP at Google and engineering and he had hundred plus reports. And, uh, one of my favorite quotes from him was that engineering is easy. People are hard. If you think about it, you'll spend four, six, eight, 10, whatever years studying software engineering, computer science, et cetera. But generally, I mean, before your class, there's very little of this in the anywhere. People don't study how to work with other people, especially on software, which is, can be very complicated, can be very challenging. And the, you know, the interpersonal components of this, which some people call soft skills, which I really don't care for because they're there. They're vital. They're absolutely important. Business skills. That's the most important part. That's the trickiest part. Your compiler is, is a wonderful thing. It is incredibly predictable. You feed garbage in a day, you're going to get garbage out today. If you had the same garbage into tomorrow, you get the same garbage out tomorrow. But I can come in today and be like, good morning Ben, how are you doing? Hey, how's it going? Great to see you. Yeah, great to see. And I come in tomorrow and, and good morning Ben, how are you doing? I hate you. Go away. Yes, exactly. People are a giant collection of intermittent bugs and they're unpredictable and that is super tricky.
Speaker 2:Yeah, I would argue that, you know, the analogy I give to students is that what you learn at school is, is the technical and the programming skills, which are important. But you know, the analogy I give is like, okay, now you know how to use power tools and do carpentry. And like it's, it's the foundation, right? But that doesn't mean you're suddenly ready to like join a construction crew and build a house. Uh, because that is a very coordinated activity that requires a ton of collaboration with people. They all need to know how to use power tools. Sure. Right? But that doesn't mean you're suddenly able to build a house by yourself. Um, or another, another analogy. Go choose the best cooks in the world and put them all in a kitchen and see if you have an award winning restaurant automatically. Right? It does. It doesn't work. There's even bigger personalities there. Um, so yeah, like the, the thesis of our book is essentially that yes, technical skills are our foundation, but the other foundation is, I mean, for programming programming as an abstract skill, right? That can be solitary, but software engineering is inherently a social collaborative activity, right? The phrase we use is, it's a team sport. And so having these scopes, social skills, these ability to collaborate with people and organize and, and have some humility about it, that is just as important to writing software as just knowing how to write code, it at least is important. Um, so yeah, it's tricky, right?
Speaker 3:It is. And this is, I think a lot of people get that sort of thing wrong. I mean, one of the things as I've built my team over the past five and a half years, and even at Google as well as you interview people in your, you're testing their technical acumen and want to like know how well they can code and what, how well, how good are they at algorithms and data structures. But one of the other things that you're looking for is what we call[inaudible] emotional intelligence. Like how well can they gauge how someone else is reacting to them and how they're working with someone else. And, and, and like, it's just so key to be able to hand things off and to collaborate with other folks. And that's, that's really vital. It, I would say it's, it's probably the most important thing that I interview for. I've interviewed plenty of engineers who are very smart and know a lot about, you know, big O notation and they can just, you know, crank out code and whatnot, but they couldn't collaborate or couldn't work with another pure person. And that's, that's, that's what it's all about.
Speaker 1:And how do you, how do you, how do you test for that? Like how do you, uh, uh, you know, when people think about interviewing for jobs, they always think about, Oh, the whiteboard interview in like you said, you know, demonstrating your knowledge of algorithms and sawn how, uh, when you're considering someone, how can you test for that? Like how, how good they're going to work in a, in a team at Google, we've actually[inaudible] we
Speaker 2:explicitly started testing for this now. Like, we don't just do coding and design discussions at whiteboards. We also have an entire interview that's just about culture and collaboration and, and they're, they're, they're a bunch of hypothetical questions. Like, you know, how would you deal with this situation on your team? How do you think about working with people on there? They're all very targeted questions, but they can reveal, I would say they're more targeted at revealing poisonous people than they are telling you if the person's going to be amazing at collaboration. Right? Um, it's, yes, it's hard to know 40 minute discussion, right? You can, you can usually tell if someone's going to be horrible to work with. And that's about the only signal you can extract. And that's better than nothing. That the best thing I love is, is to get an intern. Right. Um, cause when you have an intern that actually sits with your team for a couple months, that's it. Like that they're actually doing the job right. And then, you know, are they good to work with? Do they know how to collaborate? It's the best signal you can possibly get. Um, but uh, you know, um, the, uh, the other thing that fits in, I mean like I want to hear what your, what you do at talk fits. But the other thing was if you are involved in open source software, that's a great signal on the resume. Um, because it's effectively an internship that's auditable, right? Anyone who's interviewing you can, you can, they can go and look at your change sets. They can look at your emails on the discussion list and see you interacting with people and how well you did it. Right? So it's, it's auditable, really bad for you too. It could be bad, right? But it's auditable from a technical and social point of view, which is pretty neat. Right? That's why I tell a lot of students to get involved in open source because it's sort of a preview of what it's like to work real software engineering in, in the real world. Right?
Speaker 3:Yeah. And I think a lot of that just reveals itself through the interview process as you're, if you're treating your interview more as a like, Hey, let's, let's sort of problem solve this together and work through this and see how someone's communication style is and see how they're receptive to things. You're throwing out things that they're coming up with. And as you sort of refine, I think you can often tell a lot about a person. If, if I, I think again to Ben's point, you can tell if someone's a poisonous person pretty quickly, they'll tend to be very dismissive of you or, or, or arrogant or just sort of like feel like they get everything right. Uh, and, and people that's sort of tends to come out. Um, I mean,
Speaker 2:even when you're working on a coding problem, I think there are signals there, right? How receptive is this person to feedback? Um, are they, are they collaborating with, because I mean, ideally when you, when you're doing a problem on the whiteboard, it's not supposed to be, you know, the interviewer says, here's the problem. And then there's 30 minutes of silence while somebody writes on the whiteboard. That's, that's not how it's supposed to be, right? It's, it's supposed to be a dialogue where there's discussion and exploration of ideas and suggestions going both directions. And that is a beginning form of collaboration that can give you some signal. Right? Um, so, so definitely be talking out loud as much as you can when you do in her.
Speaker 3:Yeah. And I mean, I'll just say this, that sometimes that fails and then you hire somebody and, and, and it's not, it's not necessarily a black or white thing. It could be that someone comes in and they're having some trouble, uh, dealing with someone. They've got some bad behaviors and that's the responsibility of their manager, uh, to sort of coach them and mentor them through that and point out like, Hey, this behavior you're doing is causing this bad effect. And it's, it's, it's causing difficulties and ripples with your teammates and give them the opportunity to recognize that and make changes. And then if they don't, frankly, the, the, the next thing is termination. Like it is important to attempt to address the behavior. And if you can't address the behavior, then you have to address dealing with the person as, as to whether or not they need to be in your group. That that's an important part of culture. You want to, everybody you bring into your team influences the culture and that's good. You want your culture to grow and to get better and to improve. But if you bring someone in, uh, that has bad culture, a toxic culture, getting rid of that is just as important, if not more. So,
Speaker 2:I would say that usually the damage, what's what we call a poisonous person in our book, but the damage that person can do to the culture and morale is usually far larger than any amount of brilliant code they could write. In terms of the cost benefit analysis, the cost is almost always way larger than the[inaudible] than the technical benefit, right? Yeah. So you could say you could have someone who is an absolutely like off the charts brilliant programmer, and if they're not really a good team player, if they're a poisonous person, uh, you're just not going to be interested in them.
Speaker 3:Absolutely correct. Yeah. Yeah. I mean, as a friend of ours said, got 1516 years ago, now genius is a commodity. Just because you're smart or at one in one particular metric does not mean that you are good as a good team player, a good software engineer. I would argue that people who are good team players are actually more rare than people who are good at coding. Right. At least, at least in our field, I think it's a, it's a more valuable commodity, honestly. Um, yeah. And when you encounter teams that have really focused on building a team by, with high EEQ, it shows, it is just, it's, it's almost a toxicant thing. It's so cool. I went out, uh, in 2014 I went out and spoke to a bunch of folks in the us digital service out in the white house and uh, they put together a team that he was so high that I almost passed out. It was just amazing. I literally, this was like right at, right when I was getting ready to leave Google for talk. If I hadn't signed my contract to start talk and, or had been thinking about that for six months, I would have been like, wow, I really want to work with these folks. You know, it's a case of a sum is greater than its parts, right? If you, if you have a high performing team, right. Much greater than the technical ability. Some very much so. Um, interesting. So we actually have a system that we talk about. Um, when we talk about well what does it mean to be a good team player and to collaborate? Well, we have this, uh, these three traits that we talk about all the time called humility, humility, respect and trust. HRT, we say heart. Um, and the idea is that those three pillars, um, sort of make up what it means to be a good citizen, to be a good collaborator. Um, conversely, anytime you see conflict or social conflict or something falling apart, culture wise, it can usually almost always in fact be traced back to a lack of humility or trust or respect. One of those things. Yeah. If you're, if you're doing a root cause analysis of, of interpersonal difficulties. Yeah, keep digging and keep asking. You're going to find that it's one or more of those things is the root cause, right? Somebody is not being humble, right? Somebody is not respecting somebody else or someone's just not trusting somebody else. Right? Or it could be mutual. Right. And how do you fix that? Well, we still at least gives you a way of thinking about fixing a difference if it's fixable. Yeah. So, uh, yeah, it's, it's a good, it's a good metric to use.
Speaker 1:So, uh, you know, when we think about, uh, students, uh, students usually have very limited opportunities to develop these kinds of collaborative skills and to work in teams in, in the way that they would, you know, in, uh, uh, in, in the software industry, in a software job. Uh, when you're hiring someone who is fresh out of college, like how, how do you become that? How do you help them become a better team player? Or are there any like particular behaviors that you consistently see in recent graduates that, that you sort of like feel, okay, this, this, you know, we need to work on this, et cetera.
Speaker 3:I mean, I, from my perspective, like it's put the, you put them in a strong team and, and they, they learn from what they see around them. Uh, if you put someone new, fresh out of college, right in, in a team of like, you know, three or four really strong engineers and one or a couple of whom are fair at their senior, they're going to look around very quickly and understand what the behaviors are that are expected and how to do this sort of thing. A be a strong mentor, preferably a senior person who's not on that team and who they don't work with every day and then see like even it's going to be one on ones with their direct manager. Uh, I'd also do one on ones every month with people that report to my managers under me. And so it's, it's a, it's a lot. That's a lot of different things from my perspective. What about you Ben? I was going to say that
Speaker 2:the thing that is most coachable or perhaps the most, uh, I think that's maybe the first thing that, that folks have to learn out of school is, is the humility part. Um, and what I mean by that is, um, people are so used to, you know, doing homework and getting graded on it. But it's, it's a different kind of feedback that you get them when you do code reviews in the real world, right? Real software teams, um, designs are often written collaboratively. Code sometimes is written collaboratively, but if it's not a good team, there'll be tons of code review and their code review, they come back and they say, Hey, I would, I would've designed this differently. I would change this, change that, which is very different than, you know, yeah, your code worked or not. Right. Um, and uh, a lot of folks take it personally, right? They, they, they have, their ego is sort of wrapped up in their product, right? They think, Oh, you know, you're, you're, you're telling me to code this differently than I did. And they interpret it as you, you are judging me or you, you're not respecting me. When in fact, I'm part of a part of it is you have to detach your ego from it, right? You have to be a little bit ego-less or a little bit more humble and just say, ah, you know, this is a skill like carpentry or anything else. And someone's showing me how to, you know, use the lave better. Cool, right? This is not a personal judgment. This is just, you know, me learning from someone who's more experienced and uh, and be thankful that you have that kind of feedback coming in and it just makes the product better. Right? That's, that is one of the greatest examples of teamwork is that a, there's a phrase, right? Um, many eyes make all bugs shallow. So code review is based on that concept, right? If you have everyone in the team looking at code instead of just one person writing it and nobody pays attention, um, that, that that's a risk. If everybody looks at it, you get much higher quality product, right?
Speaker 3:And, and I think it's worth explicitly stating that the goal is to make the best product. It's not to make the product in a way that you particularly envisioned it or saw or like you don't have to solve the problem in the way that you necessarily wanted to solve it. Your glory.
Speaker 2:Right? Like, and maybe that's a little bit of a mind shift, right? It's not about what grade you get personally, it's about, Oh, this is shared stakes, right? We are either all successful together or we all fail together. So it's not about, Hey, did I write this brilliant piece of goat over here and my getting recognition for it doesn't matter. That's not like there should be a team ego and that should effectively supplant your personal ego or at least have dominance over it, right? It's not that you should have zero ego, but the team, he goes more important. Right. And the team,
Speaker 3:early on in, early on in subversion, we needed a long, a long ops for command line options. You remember how[inaudible] support that? I don't remember that. And I, and I was like super new to writing C at the time and I, I like cobbled something together that worked, but it wasn't particularly great. And uh, it was, I think it was Greg Hudson who was like, yeah, like, let's see here, let's talk about this buddy. You know, and he, he basically rewrote the entire thing and I could, I could, I could have been very upset about that and be like, well, you know, I wrote it first and blah, blah, blah. But what he did was so much better and reading his coat and working through it with him was so education for me, you know? And it just, it made me a better program. Right. I was grateful for that. Well, that's, that's part of having the[inaudible]
Speaker 2:growth mindset, right? When you're in a team, you want to be learning all the time from your teammates. That means having a lot of humility and the ability to coach each other and learn from each other. Right. So,
Speaker 1:Hmm. So, uh, moving on to something a little bit different, um, how, how do you go about, uh, like putting people together in a team? Uh, obviously, you know, lot of people have very different personalities. Not all of them are going to work well together. What, you're sort of creating a team that is going to be working on a specific project, a specific component, et cetera. How do you, how do you figure out how to build that team?
Speaker 2:All I can say in a big company, usually teams aren't just created a thin air. It's not like, Hey, we need a team to do X. Let me just choose 10 people you know, from, from across company and put them together. That's, that's usually not how things go. Things tend to be more organic, right? Which is, Oh, here's a team. It's very large. We realize there's a sub problem that really is so special that it probably needs its own team, and then we say, Oh, well look, there's already people in this team that are working on it. Let's just divide them off and call them a separate team, right? It's like, it's like my TOSAs, right? That's, that's the most common way teams are formed, but also there's sort of a continuous process of teams changing over time where, Hey, somebody leaves a team because they're there, they're ready to move on to a new problem. Hey, this team needs a new person because they're a little bit shorthanded. Cool. Here's a new hire or someone looking for a change. Let's move them to that team. So there's, there's a matching of interest and such. Right. You know, um, I, I realized there, there is sort of a pop psychology answer to this question too. And now that I'm thinking about a little more, like if, if the question is, you know, how do you decide what sort of people would work well together on a team? Um, and if you really did have the power to sort of mix and match different personalities, right? If we're talking about social skills, they're there, there is, I'm saying pop psychology cause there is a system, um, that some companies use. Even Google delves into this a little bit. We teach classes on it. Um, it's sort of a modified Myers Briggs personality analysis, which I think is pretty much has been debunked as having any real, uh, you know, concrete. It has some value, right? But it's a little bit imaginary, let me put it that way. Um, so one of the things we do is we, uh, we have a sort of a, a team exercise where we ask people in the room to identify themselves as being dominant in one of four personality types. Um, and which of course is ridiculous. Like nobody, nobody is that narrow minded writer is just one, you know, that you can categorize somebody that way. Right? But, um, as an exercise it's fun to say, Oh, of the four personality types described here, I fall into this category mostly, right? Most of the time. And then what happens is then we start talking about, well how do these personality types get along with each other and how, how do they look on a team and how do they balance out on the team? And it's actually, um, even though it's not scientifically rigorous, it actually turns out to be useful in practice because it, it creates a framework for communication. Oh, this sort of person operates this way. Therefore, I need to describe the problem or my complaint to them in a slightly different way that I would have that that's going to be more, uh, understandable to them or they'll have more empathy for it. Right. Um, but sort of a shorthand for working style, working style, but as like, as a manager for example, it's something I use a lot when I, when I have a one on one with somebody, I'm like, Oh, this is the working style of this person. That's one of these four categories. I'm going to tailor my communication now to match that working style. Right. So that it resonates more. Yeah. Um, so for, for, I'll give you an example, but I am sure we can find links on the web that talk about this categorization. But one example is, um, there are folks who love to start to projects who are extremely, uh, enthusiastic, optimistic. They love, um, they, they think big and they want to take big risks and they sort of jump in and start projects. Their weakness of course, is that they never finish what they start. Right. So, so you might match somebody like that with one of the other personality working styles, which is somebody who is very meticulous about tracking details and making lists and um, being, being closing every loop and checking off everything and finishing what the other person started. Right? Um, and it turns out if you have two people like that working together team, they, they balance very well, right? They tend to, um, together you end up with a team that does ambitious things and finishes them, right? Just, just an example of, of how you can combine personalities. But again, this is an art form. It's not science, right? So, um,
Speaker 3:but, but it's, it is very effective as a way of, of thinking, uh, thinking about these things quickly as you're going through this. And you know, I think a lot of people label it as opposites attract, but I would sort of label it as, you know, differences sort of cover different sides of the circle. If you have two people that are always looking in the same direction, they're going to have a huge blind spot behind them. But if you have one that looks 180 degrees away from the other one, you're going to get better carpet argument,
Speaker 2:city and teams in general, right? You can have diversity of backgrounds, you can have diversity in your working style, right? All of these things just actually make your team more dynamic, more. Uh, it makes your team smarter, right? You see things, you notice things more. If everyone in the team is a clone of everyone else in terms of their background and working style and opinions, you end up with products there that are like you say, have blind spots or are, are not resilient. Right. Or, um, so it's,
Speaker 3:yeah. And that's like an hour from my perspective. Like right. We're writing, writing software for restaurants and the hospitality industry, wineries, breweries, that sort of thing. And it's really important to me that the team that we have working on this software reflects the people that use this to some extent, you know? And that, that means that we've got men and women that we have, you know, people of different ethnic backgrounds. And my support team is a lot of people who have worked in restaurants before. And so they, they're sort of part of the feedback loop and they can, they can really be like, yeah, like this particular thing when they're looking at something, this is going to cause this problem or this and this isn't how's folks use it, et cetera. So it's really important to have people writing your software that reflect the people that, uh, use your software. Empathy comes around to empathy, which I'll argue, yeah,
Speaker 2:this is one of the weaknesses of Silicon Valley tech in general, right? Is that, um, there's a lot of homogeneity to the employees, or at least the leaders there who sort of have been so engrossed in Silicon Valley. I mean, Silicon Valley culture is its own sort of weird world, right? And so they, there's this common failure mode where these big tech companies produce products that are accidentally only relevant to their own culture, right. Um, because they, they don't have enough diversity of, of backgrounds and perspectives in there. So yeah, it's a problem.
Speaker 3:One of the thousands of reasons we live in Chicago. We don't live in Beckley.
Speaker 4:Okay. So I think with that, we can wrap things up for this episode. Uh, benefits. Thank you so much for joining us and for sharing all of your wisdom with us today. Oh, you're welcome. This is our pleasure. I'm super excited that you're teaching this class and I think everybody in this class should really remember that they're lucky that so few places teach this and it's going to be a real asset when you get out there and start looking at, this has been super, super fun. I love talking about this stuff. So please, anytime you want to hear more, find.