Psychology To Software Engineering - Interview With Sofia Sarhiri

Hi, I'm Nick Oentino and I'm a principal software engineering manager at Microsoft. In this video interview, I sat down with Sophia Sirhiri and she has a background in psychology but also is a software engineer. Now, I love discussions like this because we get to hear someone's background coming into software engineering that might not be classified as traditional, but we also get to see some perspectives that aren't generally looked at when we think about software engineering. Now, this conversation is great because we get to focus on communication. And if you know me, I love talking about soft skills and things like communication for software engineers because I think that it's very undervalued. So if that sounds interesting, just a reminder to subscribe to the channel and sit back and enjoy. I'll see you next time. Sophia, do you want to give us a little bit of background from kind of where you started, how you when you first knew you wanted to get into this and and how you got here? >> Oh my god. I would love to give you not just a little bit, but a lot. >> Let's go. Yeah. Um, before we started this video recording, I actually asked Nick, I was like, "Should I give a little or a lot?" He was like, "You're good. Give a lot." >> Yeah. The whole thing. Yeah. >> Yeah. I'm Sophia. I am a Dallas-based software engineer. Um, but I was not always those things. Um, things have changed for me to get to where I am. I actually my background is in psychology. I have a bachelor's degree and a master's degree in psychology. And with that, I have worked in a bunch of different fields. Um, I've worked with kids. I've worked with kids with special needs. I've worked with adults in the forensic system. Like, I'm going to say that general, but what that means of what that means is I've worked with adults who have been like incarcerated or needed a psychologist who like does tests and then goes to trial. So basically I would like give people these tests to determine if they had certain personality disorders or like different types of disorders and then I would go to court and I would testify based on my like professional opinion on the situation that happened. So that was really cool. But it was a lot cuz usually when you need to bring in a psychologist this person has done something that requires a psychologist to come in. It's not like >> you know like oh it was a car accident or something. >> It's probably never a walk in the park right? It's like probably almost always like pretty intense. >> It is. And you know people I mean people are different, right? So you meet people who are there who don't want to be there. You meet people who are there who are having like a normal conversation with you and are like some of those people you wouldn't even think were there for what they did, right? Like this person is >> having this conversation with me and I like look at the file and I'm like, "Oh my gosh, you killed six people. Wow." Um and you're just like, "Hi, it's so nice to meet you." Oh my god. Yeah, let's do this test. I'm like, oh my god, this is and you know I have to be unbiased and it's a whole I mean you have to get like higher education to that type of thing for a reason, right? Because sometimes things are not as they seem. Sometimes you have to be completely unbiased, right? And you have to know what you're looking for. You have to know the context. Um but anywh who after that I did some social work >> um just because I kind of wanted to get out of that space and so I've learned a lot from the experiences that I've had. Um, but at at you know, I hate to say it, but sometimes in these fields it's hard to make a living. Um, and it's >> it sucks because it is a really rewarding job, but you know, when I'm struggling to pay the bills and I'm struggling to do a lot of things and at the same time, I also kind of saw from my experiences that even though I'm working with these people, there is a lack of technology in the psych space. >> Okay. Um, and that's really what got my foot in the door. I just remember like everything, all the exams I was administering as a forensic psychologist are pen and paper. Um, and yeah, they do have them online, but like it's a whole filing system. And I'm sure it's different in different counties and different jurisdictions, but for us everything was like on like by paper. Um, and then when I was a social worker, everything was pen and paper. All of the resources we were giving we would like print out and things would be getting lost. There were a lot of times my supervisor was like, "Oh, I need this, this, and this." And me and the other social worker at the school are like, "We literally gave you this, this, and this last week when you came." Like, we remember fondly, you know? And so I started learning JavaScript because I was like, I want to keep a record of everything that we do because I do not like it when I'm told that I don't, you know, I didn't do this thing and I know I did it. Um, >> and then so I started learning JavaScript. Um, that turned into me making like a little messaging system where we just started scanning the paperwork and like sending it to the students and they would print it out. It was like a whole thing, but it was really cool. And um, I started talking to my friend who was a software engineer and she's like, "You can do this. Um, you she's like, "You have the skills. You obviously started teaching yourself and you were able to like do this little thing and it's really cute. um you just need some structure and you just need to learn this stuff and you could be a software engineer. And at the you know we have this thing where we're just like oh my gosh software engineers are like these magical people who just press buttons and like hack things and we're going to talk >> math wizards like you had to be born with a keyboard in your hand and like that's the only way right yeah >> and remember that word wizard we're going to circle back to it because it's really funny I did some talking with someone else and we talked about that. Um, >> okay. Before we move on, this is just a reminder that I do have courses available on dome train if you want to level up in your C programming. If you head over to dome train, you can see that I have a course bundle that has my getting started and deep dive courses on C. Between the two of these, that's 11 hours of programming in the C language, taking you from absolutely no programming experience to being able to build basic applications. You'll learn everything about variables, loops, a bit of async programming, and object-oriented programming as well. make sure to check it out. >> But yeah, and so I did some learning. I built some apps. I did some open sourcing. Um, right now I am a lead engineer for a startup volunteer. It's all volunteer- based. Um, and I've learned a lot through that, just working with other developers and non-developers and seeing how non-developers feel about developers. And it's really small, so I'm working with everyone, >> right? Um, so it's really interesting to see, you know, as someone who was a non-developer in a developer space now, just watching kind of like miscommunications. And it's funny because the topic is communication, but I don't mean to talk about this like earlier, you know, forward, but just kind of watching how things are happening and being like, I see where the miscommunication is happening. >> Yeah. >> You know, like being able to look from an outside perspective and being like, this is this is really interesting. >> Yeah. like I can see it unfolding literally right in front of me. Yeah, it's uh unfortunately very common. So, we will we will get more into that. I'm I'm curious when you were starting to dabble with the JavaScript. I'm so sorry that you started with JavaScript. I'm just kidding. um uh when you started working with it, like what aside from that initial motivation of like I want to build something that's going to help with what you're doing for work, like what kind of kept you going to like try other like build other things and like what like I'm curious about how it went from oh this is just like a you use the word cute like it's a cute little thing to like like what built that momentum more and more. >> Yeah. So, um, I am going to shamelessly shout out the Odin project for all of my people who are wanting to learn JavaScript, which Nick is not going to condone, but I love any free resource and it's a good resource. It's built by people who like run actual like boot camps and it's structured like a college course. They give you all of the projects. They give you everything's free, too. Um, and they have a Ruby on Rails course and a JavaScript course. And even if you don't want to learn JavaScript, it's really good for fundamentals. They start with HTML and CSS first. They make sure you have that downpacked and then they're like, let's start by learning arrays. Let's start by learning like just basic concepts, right? So nothing wrong with that. Um the Odin project, shameless shout out, that's how I started. I started like I literally started building my stuff with HTML and CSS first. So I learned flexbox. I was doing all that stuff and then I got into the JavaScript and I started with like an array, right? and like showing that on the screen and then you know um >> you definitely asked me >> got my momentum going just being seeing that I was able to like be a software engineer >> because um so at the time I didn't I was not surrounded by software engineers um you know I was surrounded by other social workers and my friends work in different fields some of them work with software engineers but aren't software engineers so >> true okay Um I was like um the one friend that I had was showing me like her work stuff and granted at the time she was doing like Angular. So I was looking at it and I was kind of lost because she's like you can build this now that you know JavaScript and I'm like what is on the screen? I could not do like you know I'm thinking oh absolutely not what I know. >> Yeah that's a that's a whole those are hieroglyphics. Like what am I looking at? >> Yeah. I was just like um but I was like no you know what she's right and I started thinking about like things that I could build and apps and websites and I was just like even if I don't go down into software engineering this is going to be a helpful thing to know because everything is in the tech space right so even if I decide to stay in psych or do this or do that it would be really helpful to know these things to just because like we are surrounded by technology it's a good thing and I love learning I was like this is free can do it on my own time. It's fun. I'm watching myself build things. Like >> that's I think also really cool is how >> you get this like immediate feedback with coding. Like yeah, it takes a while to learn a topic, but once you learn it, you can watch yourself implement it in real time, right? >> And I think that helps because you're not having to wait for like that gratification for a long time. It's like instant. >> And I think that's a that's really prominent. And I don't know this like for a fact but uh my assumption is it's really prominent with more >> especially like front-end development because you see like you literally see things change in front of you. Um, and don't get me wrong, like you you can make the argument, okay, if I'm implementing an algorithm and or creating something in the back end, like you can >> you can conceptualize systems coming together, but I do think that when you have front end stuff that literally changes, >> you know, just like that that you're like, "Holy crap, like I was able to like center a div." No, I'm just kidding. But like, you know, I could I could make something happen right before my eyes and all I had to do was like save the file or refresh the browser and all of a sudden it's just working. So >> that's valid. I won't hold you though. I was working on a project recently where I had to implement some backend stuff and just getting the routes like no error messages, you know, it's such a relief. It's such a relief. You don't get error messages like and it's so satisfying because you're like, "Okay, my routes work. >> Okay, like I can pull information that I need." Y um and I feel like that is also really helpful to just >> especially with the strongly type languages like it'll give you the error message right there and then. and you don't have to like go swimming for it and you're like, "Yeah, >> I joke around about the JavaScript stuff only because like from using strongly typed languages." I'm like, "How do people survive without this?" But >> no, I hear you. I hear you. And I love like I understand the benefit. I mean, I type I use TypeScript and JavaScript like pretty equally in a lot of the work that I do. Um, and I think that they're, you know, I see the benefits for why you would want a strongly type language. I'm not opposed to them. So, if anyone wants to learn them, follow Nick's channel. I would not be here if I did not advocate for the things that he taught. Um, but no, totally I agree with you. I think it's funny in hindsight. Like if I learned a strongly type language first, I would probably think the same thing. Like why would people >> not want this? >> And it's like I hold my like I as much as I joke about it, I end up holding myself back because I'm like, hey, it's not strongly typed. I'm like, I don't even know how to use that now because like I don't even know what this is going to be. Like it feels like it's just all over the place. But other people are using it effectively. So it's definitely like it is a me problem. If I spent more time using it, I would complain and joke less. But >> yeah. >> So funny. >> I had one more question on on sort of this topic though. So you're you're going through this process. When did you like or maybe I don't know if there was a moment or something, but did you have a moment where you were like, >> "Hell yeah, like I'm I'm doing this all the way." Or was it just like I don't even know like was there like a point of realization for it? Well, I mean, I had known I had known that at some point I did want to leave like human services as as a field. I considered working in hospitals as a social worker, but I was just like kind of burnt out, you know, from my job and wanting to start fresh. Um, that's a really hard question to answer because I mean, yeah, I had decided at the time like, yeah, I want to be a software engineer, but at the same time, I had done a boot camp. I'm a boot camp grad. And the boot camp was low-key kind of demotivating because there were people boot camps are really short and it's a lot of information for you. So, in a short period of time, like first and foremost, if anyone chooses to do a boot camp, I'm letting you know now. You're going to feel like you're trying to drink water out of a water hydrant, a fire hydrant, excuse me. Like that's what it feels like. And I am the type of person who loves to have a full grasp on something to feel like I really know it. And I walked out of my boot camp with my head down. I was just like, I, you know, I want to be a software engineer, but I don't know if I have like what it takes. This was so difficult. I don't know if I have the technical capability. Like I don't know this. I don't know that. I was really secondguessing myself. And there are people who were stronger than me in the boot camp because they had coding experience before me and you know really comparing myself to them. I was like I don't know I don't know I don't know I don't know. Um but I don't know I feel like actually no I have a moment. >> Okay. >> Um I have a friend who's learning software engineering and he was just having all of these issues and I remember he was like can I just get on a FaceTime with you, share my screen and have you help me? and do a little code review. >> Yeah. Honestly, and when I tell you like I literally debugged the whole thing and I knew exactly what was happening and I remember sitting there and after I just debugged this code and the error messages went away and I was like was that all? And he's like yeah. I was like >> wait. >> Yeah. I literally I was like that was so and I told him I was like this is so affirming like this is so affirming because not it was like get flow issues. It was issues with backend. It was issues with front-end stuff. It was issues with how the files were structured. There were issues. There were just issues in general for which is normal for a learner, right? Because you're learning how to do something. There's nothing wrong with having those problems. And reaching for help is like one of the best things to do. Um but just being able to identify what was happening and immediately being like, you have to do this, you have to do that. I was like, no, I know I know what I need to know. You know, I've learned up to a point where I feel confident in my ability to code. And yeah, I mean I feel like the learning process was kind of difficult because I did it in such a short period of time. Granted, I've had so much time to learn, you know, and I got like a good foundation and I feel like I'm really confident in my ability now. um between you and me and I guess the entire world which is casual. But I had a tech challenge for a job and I was really nervous to do it but I did it and I was like >> why was I even nervous? I >> I know how to do this and I did it and I'm going to submit it and I'm proud about like what I submitted, right? Um, and so I feel really confident now, but I just want if anyone out there's listening that maybe feels demotivated that that's normal. It's normal in the learning process of anything. If you choose to do higher education or even like a bachelor's degree, how many times are you in college and you're just like, "Oh my god, do I have to be here?" Like >> my entire university experience, aside from internships, the entire time I was like, "I don't know why I'm here. I don't know why I'm here." And then I would go do an internship and I was like I know why I'm here. Then back to school and I'm like what am I doing? What am I doing? Um and I had that experience you described it was my entire school experience. Um so the internships kept me going >> and without them I would have like I questioned every single time like like why am I actually here? Like is it >> is it just to get the piece of paper at the end? And honestly it felt like that for me. Um but the internships help so >> I hear you. I mean that's learning process. I mean learning is different for everyone. Not everyone's as like great in college and that's completely valid. Um but it's difficult regardless. Learning new information and then basically testing yourself on it is not going to be easy. Learning is a process. That's why it's a learning process. >> Yep. It took me five it took me all f So my uh university was like five years solid. So there was no breaks but they would put like internships like every other semester basically. So um it took me almost the entire five years of university to learn how I learned. So in the first few years I was like this is impossible. This is ridiculous. And probably like year four and five I was like oh like I know from my experience so far at university like this is how I learn. And I had to kind of just rethink how I approached everything. So yeah, it's it's a little bit of a I think what you're describing though is like a little bit of imposttor syndrome, right? And it's uh it doesn't it doesn't go away forever. It's always going to be there. And I think it comes up almost all the time when we put ourselves into these new situations where we do have to learn. >> So >> yeah, >> and that's valid. Um but I went from questioning myself. Now I'm looking for a new language to learn. Um and everyone already knows what you are going to tell me. Definitely not C#. >> Actually, no. I met a developer at the last Dallas developers meet up and he was advocating for C. I don't remember exactly what he mentioned, but he was like, there's a framework for the backend that makes the backend really similar to Node. And he was like, "No, learn C# and learn it." And I was like, "Okay, this is a really like you guys >> that's what you want." Yeah. >> I think you set him up. >> No, >> you like messaged him ahead of time. You're like, "Push C# on here." >> Are you going to that Dallas meetup? Because uh spread the word. >> Spread the word. The C gods. >> That's right. Yeah. But uh I think another thing you mentioned that I think is is worth calling out too is this experience you talked about where you were helping someone, right? Um and then you had this realization for yourself. There's a I think a really good takeaway there for other people which is like when you when you try helping others you end up real and you get this like this understanding of how well you understand a concept. So, if you would have went to go help this friend of yours and you were stumbling through it, you might be like, "Oh crap." Like, yeah, maybe I don't actually know these things as well as I thought, which is fine. There's nothing wrong with that. But I think when you go through that process of trying to help and trying to explain, I mean, you're the you're the the psych background. I'm just a just a software person. So, I don't know if this is true, but I feel like it's like you're kind of uh taking different learning paths in in your brain and like just a different way to like process the information. So, when you're sharing like your thoughts and your understanding of something, it's almost like teaching yourself more and more. But I don't know if that actually makes sense. >> No, it makes a lot of sense. and like weird out on you. But there's actually a Russian psychologist who has a theory that's completely focused on having kids that are a little bit older teach kids that are a little bit younger because they learn really well from like observation and >> Okay. >> Yeah. And so what you're saying is true and it's also because the older kids learn from reinforcing those concepts and like the younger kids. So it's this continuous like learning feedback loop. >> Interesting. Um and 100% super applicable here. We learn from teaching and the person who is learning also learns from being taught from someone who can like manipulate that information to make sense to them, >> right? And that to me like especially makes a lot of sense, right? Because I'm sure we've all been in situations where someone's uh doing their best to try and teach you a concept and you're like it's just not clicking. It's just not clicking. and someone else, it doesn't matter like their skill level or whatever, but like someone else might just approach it in a slightly different way that happens to align with you and you're like, "Oh, like instantly just clicks for you." But it's like it's really about just like communicating effectively. Which maybe is a interesting segue. >> Communication. We can take it. >> Yeah. Cool. Um, so I'm curious then on the topic of communication. So, you start working with other developers and you have this background in psychology. Um, I'm not going to say what's like the first thing you notice about how software developers communicate with each other, but no, I'm curious though like when you kind of get put into this environment because you kind of talked about it earlier like observations about people communicating like are there some highle themes that you you do observe kind of regularly with how developers communicate? I mean, I know they're going to be generalizations. It's not like can't make a rule out of it, but >> yeah, that's a really good question. I'm sorry. >> Can you answer that without offending anyone? Yeah, >> sure, I can. Um, yeah. Yeah. So, I really feel like in general, if we as a society look back maybe like I want to say 20 maybe 30 years ago, I feel like in general a lot of the people who chose the field of software engineering >> Mhm. >> chose it because they just generally tended not to want to work with people. And I know this sounds maybe like I don't know ostentatious. I feel like it's a lot to say, but I feel like if you wanted to work with people and you still wanted the same level of like difficulty and education and status that people would like do other jobs like law or physician or something that attuned more with working with people. But I think software engineering as a career and as a field and as an entity has changed. so much in the past 20 and 30 years just alone. Um it has become something where we were genuinely probably just working with machines all the time to something that is a lot more personentric now >> right >> um it's and that's not it's not just tech right everything as a whole has changed just 20 30 years because of time passing by like that's how society works um and >> I feel like >> the stereotype definitely has stuck to the dev community. >> What are what are you saying here? >> Um, if you know, you know. No, I think the stereotype has stuck to the dev community, but at the same time, I feel like there are issues in communication in the tech community. And I'm not just saying that from what I've seen because I've seen it. I'm saying that as something that in my boot camp they highly stress being able to communicate technically. >> That's good though. That's good. >> Yeah. And and you know the the thing is for me keep in mind I'm a psych major. I did I worked in psych. So I'm like okay communication like yeah that's important sure like you're really stressed but I did not realize why they were stressing to communicate >> because we don't do it well. >> And it's not anyone's fault. The thing is you know developers are really smart people that you developers are really smart people and sometimes sometimes your knowledge is your weakness. No I'm joking. Like it's But sometimes it's not about being smart. Sometimes it's about knowing how to pass the message you're trying to pass along to the person. >> Exactly. >> Exactly. Which is it's interesting, right? Because I think uh and we see this happen a lot where when you have it's I mean it's going to be normal that you'll have some type of uh conflict at work. And when I say conflict, I don't mean like literally people fighting with each other. I mean like difference of opinions, right? there's conflicting views on something and it's pretty common that you will have individuals where the goal in conflict like that is to prove that they are right. Yeah. >> So Sophia, if you and I were disagreeing about how we should go design something and I'm like, "No, it needs to be written in C because C is the best." >> And you said, "No, JavaScript is the best." And all that we're doing is trying to tell the other person why we are right. It like it doesn't we could be the two smartest people in the world. I mean, we might very well be the two smartest people in the world, but um it wouldn't matter because if you all you're doing is like trying to prove that you are right without actually communicating effectively to your audience, then like the entire message gets lost. >> Yeah, that's very valid. Um knowing how to communicate is important. Um I have a bunch of problems that happen in textbased communication. and I'll like walk through them later, but um this is kind of a great way to move into some of those things. Um knowing how to communicate, right? That's a really big one. And so, one thing in the tech space is that a lot of the meetings we have are through the computer. There are still people that work in person and in the office, and that's great, but generally a lot of the work that's done tends to be remote. Um that being said, it removes a layer from the communication we have and that is um non-verbal communication. Um non-verbal communication communicates a lot. You can tell a lot from if someone's tapping their foot really fast, if someone has their arms crossed, the way someone's facing when they're sitting, right? So we've already gotten rid of a layer and almost created a barrier by communicating digitally. So we have these communications in tech that are already happening and we create this layer of this barrier of communication and I mean it's hard with the startup I'm working at right like I have to get in touch with the project manager and this person that person this person that person everyone works in different time zones and you know I'm like exhausted half the time and I'm like I'm sorry I'm drinking coffee and and I'm trying to video chat everyone and it's just sometimes like a lot. >> Yep. And I uh it's the the non-verbal communication, the body language and stuff. It's uh it's interesting because when I had left the startup world to come to Microsoft, it was also like right at the time when uh lockdowns were happening from the pandemic. So I went from being at a startup working with my team like we could turn in our cubes. It was like cut down cube walls. So basically just like an open concept but we would turn at our desks we could chat um to like I am completely remote from my team that's new to me that I'm managing and I remember thinking like there's so much about body language that I took for granted because even like on this call right now right like I can see like shoulders up uh but I can't tell if you're fidgeting. I can't tell if you're tapping your leg cuz you're nervous. Um, there's so much that we just like I think like automatically and maybe it's subconsciously as as we're communicating that there's so many signals we pick up on when we're talking to someone. And when all of those are removed, it's like I can't like for example, I don't think that you're nervous or feeling awkward on this call right now, but if I could see like your entire body, you I might see that you're tapping your leg and I'd be like, "Oh, maybe Sophie is nervous. maybe I should, you know, approach this differently. >> 100%. And even with like interviews, right, as an interviewer, um, just seeing those things is helpful because you can be like, "Okay, this person's nervous, so if they stumble when they speak or something like that, I'm going to take it as a sign of their nervousness, right? Not as a sign of anything else as you." And that's like the only like signal I get now, especially with like uh like remote interviews, is like I have to listen to people's voice. Like if they're like if I can tell they're like uh they're starting to stutter or they're tripping on their words and stuff, I'm like, "Okay, like you know, I'll try to calm them down, make sure that they feel good to go." But again, when you're in person, there's just more signals that you automatically get. So yeah, the communication part there is is very interesting because I don't think a lot of people think about that. It's like like even I didn't until it was removed and then I was like wow that makes a huge difference. >> No I mean there's a whole study on just body language and how it works right and I mean some of it is pseudocience some of it is science science but the science science says that body language plays a role in our communication. Before we had language we were communicating some way right we were working together as humans. Um so that already creates a barrier to communication. I feel like the other thing is that software engineering is like a pretty complex process and it's not just software engineers. Software engineers are working on a team usually um with other people with a program or some type of manager managing a project or something right along these lines. Even in a startup, you're working with other people to get a project off the ground. And so this is a really complex process. It's not just software engineers with other software engineers. That would make probably a lot of problems go away. Um but >> probably it would make some other problems even worse. But yeah. >> Yeah. But we're also adding a lot of other people to the equation. And it's >> I think that we we need to focus on learning how to communicate >> and also communicating with people who are not familiar with software engineering. And so we kind of have like these two facets of of communication that are important. Um and I want to give you an example of what I'm talking about, but like not a software engineering example. >> Okay. Okay. But like I don't know, let's say you're hanging out with your friend and your friend starts getting some chest pain and they fall on the ground. They're freaking out and you call 911. You go to the hospital with your friend and the doctor is talking to the other people or he's talking to you or you know he's talking to someone and he says, "Yeah, you know the patient suffered a myioardial infuction and this was evidenced by elevated tropenin levels. We're going to need to initiate reprofusion therapy." You're not going to know what any of that means. >> No, that person's dead to me. They're I I'm sorry we couldn't be saved. I don't know. >> What I just told you is that your friend had a heart attack. >> Okay. Yeah. >> Do you see how my language completely changes your understanding of what's going on? >> Yeah. I went from uh I'm scared to like I still have absolutely no idea what's going on, but it sounds terrifying, but no concept of what's happening. >> That's valid. But um you know it's the layman terms. It's communicating in a way where the average Joe can understand what you're saying because not everyone's a doctor. And typically I mean in general people tend to prefer doctors who explain what's going on to them more so than doctors who use medical jargon a lot. And the thing is this doesn't just happen in doctors. It happens in anyone who is a professional in their field and surrounded by other professionals in their field. Because why do I need to know how to speak to someone regularly if I'm surrounded by doctors 24/7 >> who who require you to speak at that at that level right because the details of what you're saying are really going to matter because if you just said heart attack to another doctor who understands more of the technical jargon they might say well like I don't know enough about this like what what what kind of heart attack how severe I don't know the different ways to quantify or qualify it but they would need those details >> yeah and I mean but I'm what I'm talking to you who's just this guy's friend who's a software engineer and not a doctor. It would make a lot more sense for me to be like, "Your friend had a heart blockage and it caused him to have a heart attack. We're giving him XYZ medication to get rid of the blockage, but your friend might have to come back and have surgery is so much more easy to understand and >> less complicated." >> Yeah, absolutely. And like I can I I'm a little biased, but I can absolutely see how that like ties into like software engineering situations, right? Like again, um if we're talking about it doesn't even have to be like non-technical roles. It could be literally other software engineers on different teams. >> Yeah. and you're talking about some part of your tech stack and um and explaining the details of it and like they might be a software engineer too and they're like I literally don't know what you're saying to me because I don't know like this particular domain and you could imagine that gets even worse when you have to uh I was going to say deal with I don't mean deal with I mean like work with uh like other non-technical roles so maybe you have a uh a project manager or a product manager that is non-technical to know those details. You're using technical jargon that they might not be familiar with. Like what is your expectation of how they can use that information? They're probably going to look at you like, okay, so what? >> It's really funny that you say that. I have a friend who works at a big company which shall not be named. And he's a tech he's in tech sales. >> Okay. >> Um and he sells his company's software. And when I became a software engineer, you know, I was like showing my friend my resume cuz I'm like he's tech adjacent. You know, he can help me out with this stuff. He's like, "This is really cool. I don't know what half of the stuff on your resume even means." And then he's like, "Can you tell me what No SQL is or can you tell me what is?" And I was like, >> "Sure." And so I explain like a SQL versus NoSQL database and then I explain specifically. And he's like, "Oh, that's really cool. Like my company uses and I don't know what it is. I just tell people like we use it in our tech stack." Like, >> you know, and it's like I I I just sat there and I was like, "Oh, >> so you don't So you're selling and I don't it's not just him. That's just how the field works, right? They're selling this technology and they don't know about it deeply. And it's not just the tech sales. It's a lot of the stakeholders, a lot of the project managers, anyone that's really not in tech doesn't necessarily think that they have to learn about the tech stuff. >> Yep. It's true. >> I don't blame them. >> Yeah. And I mean, there's if we think about the different responsibilities of the different roles. They're going to have their own key things that they need to know, but I would say I've talked about this before even from like a management perspective, like a like a people manager. Um, but I think from my experience, the people that do the best in software engineering as as non-software engineers, like just adjacent roles to it, um, like parts of the team and stuff, >> uh, they're the ones who can be technical. And I don't mean like they have to code, they could like, you know, bust out Visual Studio and type up and whatever. I just mean like they they can relate in the sense where a software engineer, say a software engineer is trying to communicate and they're trying to simplify something, but they're having difficulty getting it to a really simple level. If someone in a different role that is non-technical is technical enough where they can bridge that gap more effectively, then all of a sudden your overall communication just is better. >> Yeah. If you have someone who's completely non-technical and they haven't put any effort into learning some of the technical pieces, then you're going to have individuals that struggle to communicate with them because it's already challenging for them in the first place to like relay their ideas. >> I agree. I agree and you said it really well. So, I think that we should look at this both ways, right? With our software engineers, I understand maybe you don't want to talk to people. Um, I hate to throw you under the bus, Nick, but Nick admitted to me that he was introverted. >> I am >> very fair to be introverted exist in life. Yeah. And that's totally normal. And I'm sorry that you have to talk to people, but it's just >> job. >> I picked a weird career path for that, right? Like as a as an engineering manager. Yeah. It's a weird fit, but >> um and that's totally fine. But at the same time, we should at least have like a basic understanding of how to communicate with other people. And I feel like part of that has to do with just giving your co-workers honest feedback. If you go somewhere and you might not have great communication, I would hope and assume that you know your peers are able to communicate that with you and set boundaries and say, "Hey, this is what we need from you, you know, for things to be able to work." Um, and I'm not speaking for people that have like that are on the spectrum who have difficulty communicating. There are things to help them in place. I'm talking about normal people who just do not like interacting with other people. Normal people. Yeah. >> Yeah. >> Um, and it's valid. But for, you know, your like 10 minute meetup, for your 10 minute, you know, just just drive out like >> Yeah. you know. Um, but I think our software engineers and especially I see this a lot in software engineers that are like super senior software engineers that have like these really high positions and are surrounded by other like software engineers that have really high positions is they don't really take into consideration even like junior engineers or anyone that's like outside of the tech. >> Um, >> so I think that kind of like we were talking about doctors earlier, it's something we see across fields. That's why it's a thing. So, I think being able to communicate your technologies or like an exercise could be trying to explain what you're doing to like a child. And I know that sounds funny, but I'm so serious. Like, if you can explain it to a kid, you can explain it to anyone. >> Yeah, it's true. Um, it's funny. U this is going to be the worst timing for a comparison because you just said to a child. So, let me I want to have a disclaimer here. I'm not about to equate this person to a child, but when I sometimes talk to my wife about things I'm doing at work um and I no I go to talk about technical things, I'm like I know that she and not because she doesn't like me or something. I know she doesn't care about the technical details >> because like why would she she doesn't get exposure to them, right? Like it wouldn't make sense. So she like she knows if I'm excited about something or if I'm bothered by something like she she wants to be part of the conversation with me. But then I have to go through this exercise of like okay like I'm bothered or excited by something and it's technical or there was something that was going on. So then I have to go okay like what's a way that I can talk about this in a way that she's totally going to be like oh yeah like that absolutely makes sense. I could see why that would be exciting or would bother you. So it is a really interesting exercise. Again, not equating her to a child, but >> no. And that's fair. Finding someone in your life who doesn't understand technology and trying to explain it to them. Um, my dad is a retired chef. >> Okay. >> So, he will make you the best thing you've ever, but he does not know what I do, >> right? Um, so like I'll show him I'll show him the most simple like I'll grab a a like from a database through using an API and display it on the front end and it'll just be like a list of names or something like from a movie. >> Yeah. It's magic. >> Yeah. No. And he'll be like, you know, don't get in trouble hacking someone you shouldn't be hacking now. Like he thinks I'm like capable of I don't know what. I think it's hilarious because my he'll like boost me. Like just hearing him thinking that I can like hack the government and get arrested for it is crazy and hilarious and I'm like I love that. But I having to explain what I'm doing to him because he's not he doesn't know what an API endpoint is. He doesn't know what >> even a front end and a back end like I had to explain those to my parents. So just explaining to him what I'm doing and then he'll be like, "Okay, I get it." Right. And I'm like, "Okay, I know I've communicated this effectively because someone who >> is not techsavvy." >> Right. Absolutely. Well, and you said something interesting too about like the I like the comparison between individuals say they're like a lot more senior surrounded by more senior engineers. You did that comparison to like doctors and professionals, right? Um, I have had experience with people that are like that where a lot of their peers, you know, are very technical like them and I've seen them take opportunities to help teach like more junior people and stuff and it's really awesome when people are able to do that because um, if they spend the time trying to ensure that they can communicate things like uh, effectively to I don't want to say like non-technical people, I just mean people that don't have that experience. So, >> when they're able to do that um and do it well, like those individuals get such an awesome learning experience because they're getting it from the expert and someone who took the time to like make sure that they can explain things effectively. So, it goes a really long way. >> 100%. Um and yeah, I mean I've seen people like that too, but I've also seen people on the other side of the spectrum. Um, I've worked with someone who also shall not be named the company he works at, but he works at a a very big company and he's been like an engineer for 25 years. And when I tell you he has a vision and you know like he knows what he's doing. 25 years is a lot of time and he will give me an idea of what he wants us to do. And this is for the group I volunteer with. And keep in mind we have a lot of volunteers who are new to coding who want to learn how to code and you know he'll be like okay we need to have xyz thing and I'm like oh well some of our new coders aren't going to know how to do xyz thing so like we need documentation or you know we needed he's like ask them to use chat GPT they'll figure it out and I'm like as a super senior developer chat great tool for you because you know exactly what you're trying to like look up right >> but for a beginner that is probably the worst advice you could give a beginner who >> you're gonna get something but is it >> Yeah. >> Um and you know it's like I know you know what you're doing and that's amazing and you're so smart I probably can't even comprehend how much information you have in your brain but remember the little people. Remember when you first started like it's different it's it's it's different. Um but yeah I think that teaching other people is a really great experience. Um, I was talking to Leyon. I'll also shamelessly plug him. Cool dude. And he was telling me that with a lot of companies he works with, um, he suggests doing pair programming with either like coders on different teams or coders and non-technical people on different teams and having the coder kind of explain what they're doing as they code through. Um, not necessarily to teach them your tech stack, but to just be like, "Yeah, so this is what we're doing and this is why we're doing it." >> Right. Um, and so you have the coder practicing their technical non-technical communication and also you're getting to teach other people. >> That's interesting. Like the I think what's being highlighted here that is probably often overlooked, right? Is like um is this benefit to the person doing the communication. It's not just the benefit of the person receiving information but like >> uh because this comes up a lot where I talk about like why communication is important for software engineering very frequently. I try to remind people like hey look the technical skills they're obviously important but you're going to be practicing them all the time. >> Yeah. >> It's the non-technical stuff like your communication or your other soft skills where if you're avoiding them like when when do you get the opportunity to practice them? if you actively avoid them. So, putting yourself into situations like this actually gives you this opportunity where you're like, I am practicing this type of communication and by practicing it, I will get better. So, I think that's a really cool opportunity. >> Yeah. I mean, honestly, for someone who does not work at a company with other stakeholders, pull up a chair and have a friend sit next to you while you build a project, while you work on something. Um, work on that communication. Um, I also think that non-technical people out there who work adjacently to technical people should at least try to learn the basics. Especially if you feel like you're continuing, if you're like a project manager and you feel like you will you enjoy the field and you want to be a project manager with tech for the rest of your life, you should probably know what Git is. You should probably know what an API is. You should probably know what the most commonly used words are in what you're doing and what they mean, >> right? Yeah, >> it helps a lot, right? This is kind of what I was saying earlier where it's like you don't necessarily have to be an expert on these things and know them in and out, but when at least the jargon that's coming up like being having some exposure to that, having some basic understanding of it so that when people like ultimately end up having it happen when they're talking because people will try to communicate effectively, but there's always going to be these things. when you can try to meet them in the middle on it, then it will help a lot with the effectiveness for sure. >> 100%. I agree with you. >> So, I was curious because I know we had a couple of notes from beforehand and I I don't know what this is and I wanted to ask you about it, but you had mentioned a branch of psychology called IO psychology and I don't know what this is. So, I was very curious if you wanted to talk a little bit about that. Yeah, IO psychology is short for industrial slashorgganizational psychology and it's literally just psychology in the workplace. >> Okay. >> Um, so typically what'll happen is this is usually something that bigger companies will do because they can afford to do it. Um but they hire like psychologists to come and just based on their knowledge and like observing tell the manager ways to make the employees more productive >> but also like while keeping employee happiness up. So there's a really funny um research study that I'm going to tell you about because it's actually really hilarious. Cool. But there was a company that hired an IO psychologist and the manager was like I guess they had really bright fluorescent lighting in the in the building and the manager was like I want to see if my employees will be more or less productive with better lighting or less lighting or dimmer lighting or you know he just he wanted to see if his employees didn't like the lighting but the manager made a mistake and he told the employees they were being watched they were being observed. >> Oh okay. >> Yeah. So they like slowly, maybe hour by hour, I don't know how they did it, but slowly they like to dim the lighting and they would measure the productivity of the employees. And the darker it got, the more productive the employees were being. And it was like pitch black. Like the lights were turned off and the employees are at like 3,000% like >> Sure. >> Yeah. Like Super Saiyan at the workplace. And the manager was like, "What's going on? Like y'all can't even see, you know? Why is your productivity so good? And one of the employees was like, "Well, y'all are watching us. Like, isn't this what you wanted us to do?" So, so, so the manager messed up, I guess, by this is just kind of like a a what not to do story that >> it kind of helps explain the idea of what the IO psychologist does, right? Of finding a good balance between employee happiness and employee productivity. Um, I would not be surprised if your company had one, but like maybe one that floats around the whole company or is that >> for the size that Microsoft is, I'm sure. Um, I have so for transparency like I've never uh interacted with anyone in in such a role. Um, it's pretty like I don't know like even even for Microsoft and where I was at before. I can understand especially for smaller companies and startups why why having resources like this come in is like pretty rare just because of cost and um but I think we in general we see software engineering managers and I I'm assuming managers even in other fields do I don't know because I've only worked in software but I feel like management gets uh sort of like neglected in terms of like the skill sets and things that you should be good at or would help you and it's kind of like here you go like go manage people and you're like what does that mean and they're like we don't know but you'll figure it out and it's weird because it's like that's a pretty I'd like to think it's a pretty important role so >> it seems very weird okay okay it seems kind of weird to me that like if we're going to be putting people in front of leading others that we wouldn't try to skill them up for for that so like when you mentioned this role for like an IO psychologist. I'm like, "Yeah, that sounds like it would be very helpful to at least have some interaction with someone like that um to to learn more to understand how things work." But we barely like we'll get training and it's like take these online like quiz type things and it's like is that is that how we train managers? I don't know. It's kind of weird. >> I feel like that's how they train everyone nowadays is just watch this video and take a quiz. >> Yeah. And it's like h I don't know. Like I it's kind of like uh what I was saying earlier for like the people skills, right? Like um I mean if you were a manager and you were like, "Oh crap, I don't have good people skills. I don't like the peopleing, but they made me a manager." You will actively avoid those things. You will not practice them. And it's going to just be a vicious cycle of probably being a pretty crappy manager. So like uh not a not a good combo. But >> no, I hear you. Um, >> so they they bring in so in in these different organizations you're saying there's an opportunity for like an IIO psychologist to come in, they will like basically partner with a manager or someone in some type of leadership position. >> Yeah. Um, so typically I'm assuming because you are part of like a really big company that is like humongo I think they probably have an IIO psychologist who is just like oh on site y'all should have food and like a jungle gym. I think that was that was that like that that was really popular when the bigger companies were doing that sort of thing. I do more companies would be more >> I don't know caring about their employees and hire more people like this right because what you're gonna pay a couple more people to come in and like boost your productivity and make your employees happy and like you could for example you could tell the IO psychologist hey I feel like in managerial positions we're lacking a lot of training and that person could then go and be like well if this is upsetting you this is a change we can make how can we implement the change And like, you know, it just helps create another channel where you can um I I I'm sorry that that person doesn't talk to people on your level. I feel like that they probably have one that's just somewhere making decisions maybe not based on the company because it is such a large company, right? Like in the example I was talking about the lights, but you guys probably have people that are working remotely all over the world, you know? So it might be more about like oh after co are we going to return to in office work yes or no or it might be decisions based on that right it's not necessarily more personal but I feel like more companies should have stuff that's more personal maybe hire one person per location or you know I don't know but >> yeah have the means to do it >> I can like I can absolutely see the value in that so one thing I'll I'll share with you briefly is like uh at least in my part of where I work at Microsoft there's the surveys that go out I don't know the frequency it might I don't think it's every quarter it might be every half and uh they're called signals and basically it's a survey that goes out to everyone so not just uh you know uh individual contributors but to managers as well it goes out to everyone and it it's anonymous and it kind of the information bubbles up to different levels of management so they can see like um the trends right so for example if I only had a couple people uh that submitted them to me If there's not enough, I can't even see the results because it would be telling of who submitted it. But that information could bubble up through my manager and he could see the overall thing. So >> in these surveys, there's a bunch of stuff that is really I think ultimately comes down to like how much do you love working here? Like that's kind of what it is at the end of the day. But the questions are framed in a way that help us try to I don't know like guide our actions for like different things we should try doing. like hey like do you feel like you're learning on the job? Uh do you feel like uh managers give you those opportunities? Do you like >> different things like that? >> So I find it interesting when you're talking about like an IO psychologist because when we go through these things we actually like I know some people probably like oh man we have to do this stupid survey. Who cares? But like we try to at least in the teams that I've been on make a point to say like submit them. Please submit them. we'll hound people to do it because then we go through the results and we talk with the team about like here's what we're going to try to do to make things better. So what's interesting to me though is like we're all managers that have probably never have had like some type of training from like a psychology perspective. We're just we were put into it. We've been doing it for a while. But like are we professionals like in psychology? Absolutely not. Um, and I think it would be so helpful to have someone with that perspective be like, "Hey, like before you go down this path, like here's some insights." >> That's very fair. That's understandable. Um, I don't know. Take it up with Microsoft. >> Yeah. Tell them. Get us Get us one of those IO psychologist Sophia said. So, >> yeah. I'll I'll write you a little paper with my name on it and sign it like a doctor's note. >> Yeah, that exactly. A scribble. That would be perfect. >> Honestly, they can't even read it. >> That's great. Yeah, I would I would love that. I'm gonna make sure that you send that after this call. So, um >> do >> you have to? >> No, that's cool. Um is there anything else from your perspective on the communication side of things that like you feel doesn't get talked enough about from like the perspective? Like we talked a little bit about like there's body language. We talked about um like understanding how to communicate effectively. Uh maybe maybe I'll kind of throw one out there if you don't have an idea. The one that comes to mind for me is like written communication which is is obviously we talked about non-verbal but like purely from the written side of things because we are writing code right. Um, do you have any like from your perspective so far, have you had experiences where like you're stepping back from looking at how written communication is and being like, man, like there's some gaps here and like we could do this better. >> I mean, yes. I feel like what happens is I feel like best practices when you are learning how to code or maybe when you're a junior dev are pseudo code everything you do. Make sure you understand what you're doing. Make sure someone else who reads your code knows what you're doing. But I feel like when you are crunched on time trying to submit a ticket for a deadline, that goes out the window. You are writing the code, the code works, the code gets sent, and that's that. Um, and I don't think there's anything wrong with doing pseudo code. I mean, there's nothing wrong with understanding your code and going in and kind of writing out what's going on. Maybe I don't know if you work somewhere confidential and like they just don't allow like there could be situations where it's not okay. >> Sure. >> But there's nothing wrong with pseudo code because at the same time you're explaining what's going on. like if I am able to understand what your line of code is doing through the text that is right there, then you did a good job explaining what that line of code was doing, >> right? >> Um that being said, again, we already talked about like different levels of engineer. Um I feel like documentation might be seen as such a beginner thing like, oh, you're learning how to use such and such, go read the documentation. Oh, you're learning how to do this, go read the documentation. But someone who's been doing it for like a thousand years like does it need documentation? >> They are the documentation. >> Yeah, that's right. It's up here on Stack Overflow. Yeah. >> Um but again with the communication just because we reach a certain level of coding proficiency doesn't necessarily mean we shouldn't also be focused on whether or not we can explain what we're doing. Um with documentation sometimes I think it can be seen as more of a nuisance to make than true. helpful, but it doesn't hurt. >> I had a whole rant on this on a vlog where I said like I think that this my personal opinion is like documentation is extremely helpful. >> Yeah. >> But it's it comes at a cost and basically there's an enormous cost to maintain documentation to keep it be being extremely useful. >> Otherwise, you just have documentation that sucks. >> Yeah. And then it's easy to m it's easy to maintain because you're not maintaining it at all. Right? So there's a weird and I I don't I've never seen a good solution to it. And I wish that there was because you don't have it, people don't have the resource or you do have it and it's awesome, but that's like someone's full-time job is like maintaining documentation. So >> if you've watched this far, comment down below what you think the solution problem is. I joke. But no, I think that's accurate. Um, in a lot of the groups that I've worked with, it's usually one person's job just to do the documentation, and usually we send them like what we need. Yeah. >> What? >> And I mean, that's fair. Granted, I don't think anyone signed up just to be the documentation person. >> No, definitely not. >> I think that's a pretty rare thing. I mean, look, if anyone's hiring for documentation people, I love to write. I'll color code it. You just But I'm with you. I think documentation is important. It's helpful. That's how people learn how to do things. Um, whenever I'm using a new library for anything, I always read the docs first. The docs will literally explain things to you, have code blocks for you to use, like, >> as you should. I don't I haven't learned that yet after 20 plus years of programming. I'm like, "Nope, I don't need documentation." and then like seven days later I'm like, "Okay, I'll I'll read it." I guess >> that's funny. Well, when I was doing the Odin project, a lot of the times they'll teach you a concept and they'll send you to the page for documentation. And so the first thing you learn is it'll be like, "This is a framework. This is a library. This is a this, this isn't that." And I'm like, "Okay, I know what I'm doing." Like, >> yeah, that's the right way to do it. I just I feel like I'm stubborn or something and I just like I'm not I don't need documentation. So, um, >> you know, maybe you're doing everything right because you're a manager and I'm not. >> I don't I don't have to code at work anymore. So, I don't read the documentation. I don't have deadlines. It's just my own personal sad party of not being able to get code to work because I'm not reading the docs. But, um, okay, one one more question for you. um code reviews, PRs, have you like what is your perspective on what you've experienced with pull requests and code reviews? Like have you had have they all just been awesome and you've worked with people that are like very good at communicating on them or have you had some pretty lousy code reviews? Um regardless of like at the current place you're working or whatever, you don't have to give the details on it, but like your experiences with that. Oh my god, my experiences with code reviews have been great and awful. Um, I've had kind of both the spectrum code reviews because I've done a few different things. Um, so I've had like I've worked with super beginner engineers who don't even know what's going on and I've had great code reviews with them just because a lot of them are willing to learn, right? So it'll be very like, okay, you submitted your code for this ticket, this looks good, this looks good, this function isn't being called, you know, how can we fix or this isn't this and this isn't that. And they're like, "Okay, cool. Yeah." And you know, when I ask them, "Make sure you create documentation for reusable things and make sure you do this and make sure you do that." It's great. Um, and then I've looked at code reviews. Um, for example, when I worked on open source projects, I have seen code reviews where the get commit is literally just a string of curse words. >> Okay. Yeah, it sounds like my commits. Okay. >> Yeah. And I like we're doing the code review for this commit. And I'm like, you know what? The only thing going through my mind is that commit string of because you don't know what's going on when you wrote the code and I don't know what's going on when I'm reading the code, >> right? >> I mean, but I've I've I've been on both ends, I think. I mean, I love kind of like documentation. I love when things are done properly. when we do our pull requests, we, you know, I I be leaving comments. I'm like, "No, no, no. Go back and redo this pull request on line 58 on this file. This is why this is D." Because I'm currently doing some code reviews right now. Um, or I'll be like, "This was great. I'm merging it into our dev, our development branch. This was super awesome. Send me the documentation. Like, this was great." That's cool. There are some times where I'm reading people's code and I just don't understand why they went in the direction they went in. Okay? >> Right? Because everyone thinks differently. There's a thousand different ways to code something. Like as long as it gets the job done, that's just how coding works. >> And so I'll be reading the code and I'm like, I wonder why you decided to make this the async. Like I I personally wouldn't make this asynchronous, but if your heart was telling you, like sometimes I'll just be reading code and I'm trying to understand what this person's thought process was to see where they were coming from. Like it might still work, but it might not be anything that I would have considered when I was writing it. And so sometimes those will be a little bit tricky because I'll have to like reach out to some other like engineers that are with me and be like, "Hey, >> do you understand why this is working the way it is or am I bugging or >> Yeah. like is it a learning opportunity for you like or is it like should you be going back and questioning this person like hey >> so I think that when done properly I love pull requests that have comments I love getting comments I think constructive criticism is great teach me things show me where I messed up um I don't love it when people just make pull requests or do things or code review without taking the time to actually do them because then that creates a lot more issues for us moving forward. Like um so I've been trying to tell like a lot of the junior devs I work with like when you do your pull request name the branch you know your feature name and we're going to use get best practices and you know I had to lock the branch from allowing just anyone to make the pull request you know like we're using our pull request um securities and stuff like that. So and it's great I feel power. >> Yeah. Putting putting some best practices in place, right? Because it's like when you have a lot of things unlocked and everything's kind of all over the place. Like even if you have guidelines for things like people are human, they're going to venture outside of that. So if you have tools that you can lock stuff down, what's there's like a phrase it's like pushing people into the pit of success, right? Like you can't mess it up because we're just going to push you into the success pit. So >> I think stuff like that can work really well. Um, and yeah, I think I think that makes sense too, your comments on on the comments where uh if people are able to kind of clarify what's going on, I think constructive criticism is huge. I think personally um unfortunately I don't like I don't know why I feel like I don't see people take advantage of like constructive criticism on code reviews and sometimes it's just like change this. >> Yeah. So as an outsider now because when I'm reviewing code like I I like to defer to like say like the principal engineers or the senior engineers on the team to be able to really give like better feedback. But if I'm going through it and scanning stuff and approving things like it really kind of I don't want to say it upsets me but it kind of makes me feel bad when I'm seeing comments that are just like change this or like this is wrong and I'm like you could have typed a little bit more to like offer more clear guidance explain right. Um, and I feel like I feel like that's easy to do. It doesn't take much longer. It's so much more helpful. Um, it's way easier to not take something like that personally. If someone was just like, "This is bad or this is broken. Change it." Um, you're kind of like, "Well, what the hell, man?" Like, >> "What about this?" >> But when someone can explain, right? Like big difference. >> No, I agree with you. I think that also I mean no if you're nice constructive criticism is good. I was going to say sometimes I feel bad like myself giving constructive criticism but like there's no harm in being like oh this is how I would do it or you could change this to this because it would run more efficiently or faster. >> Sure. >> Explanations, right? Like I think if you have criticism to leave or feedback to leave, just take a moment to explain yourself, right? I think that just goes a really long way. So >> that's yeah >> easy to do. More people should do it. >> Awesome. Okay. Um I wanted to say thank you for for coming on here and talking about communication because I think >> uh I say it all the time. I've already said it a couple times, you know, in our talk, but I think it's I think it's critical for software engineering. I think people overlook it because we're software developers and we love technical things and it's way easier to just put our heads down and write code. But >> yeah, >> you said it a bunch, too. We're working in teams. You're working with people that aren't just software developers. >> You have to be able to communicate. So, thanks for for chatting through that. >> Oh my gosh. Thanks for having me. >> Of course. Um, I should ask any anything you want to shout out for people to reach out to you or anything you just want to shout out in general. >> Oh my god. Um, >> don't mess it up. >> Gonna go through the whole list in my head. Shout me out. You just want to talk. this whole thing was about communication. Um, shout me out if you have any questions about psychology, if you have any questions about coding. Um, shout me out in general. Find me on LinkedIn. You can find me through Nick. >> It's true. >> I'll get links and stuff from you after, too. If you want to have anything posted, I'll put them in the description and the comments and stuff so people can can find you. And if you don't want people to find you, then I won't put anything. >> Okay. Thanks. Yeah. Awesome. Okay, thanks again and we'll chat soon.