It Goes BOTH Ways - Building Trust With Software Engineers

Transcript is auto-generated and may contain errors.

Hey folks, I'm headed to the office. It is Friday. We made it through the week almost cuz we still got a full day. Um I don't go to the office on Fridays, but I've been going every single day this week cuz we got people that traveled in this car. You got to stop. And uh it's been awesome to see people in person. I literally just turned off the beeping and it's still beeping. But, uh, yeah, I've been a little flustered this week just because there's like, uh, I've been on call and we have a new on call schedule, but I'm back up, but I'm still like actively working on stuff. But the problem is, or I shouldn't say the problem, because I'm going to the office. Um, I don't want to drive home and be on call at the same time. That's not really fair. So, I basically have to stay till 6:00.

And every day there's been like stupid traffic. So I'm getting home at like 7 to 7:30. Some days I've been going in a little bit earlier to try and make meetings work. So I've been sitting in traffic a lot and I basically don't have much time uh to myself. Not complaining. I'm just saying uh it's I've been a little bit scattered because of that. Um so like for example, I have videos that were supposed to be published today on Code Commute. I have two that are ready. They're uploaded. I just I didn't get around to like putting the little description on them. So, they're not going out today. That sucks. And I won't be home until like 7 tonight because I'm going to be at work and I'm going to be on call. If it's light, I might try to not stay um just because it's too much.

But, um yeah, I'm going to I'm going to talk about a similar topic that I did yesterday, I think. Um, so or maybe it was the day before something like that. But I think it's relevant because I was just uh I just did a podcast interview uh with a guy from LinkedIn. His name's Adrian. So that'll be posted on my main channel um probably next week. Editor works very fast, especially podcast. He doesn't have to do much. So um that'll be up. And uh I think it was really cool because we were talking about um about lead his his take on like leadership pillars and a lot of the stuff like we haven't sat down to talk about this ever before. So it's really cool when we start going through stuff and it's like hey like that that actually really resonates with me and I think he had some cool ways to explain um like kind of like narratives for for why these things are applicable.

So, um, anyway, I'll I'll talk through that. Friendly reminder for folks, if you're new to the channel, yes, it's just me blabbing in a car. That's all it is. But, uh, I try to take questions. So, if you have questions about software engineering or career development, leave them below in the comments. Uh, the questions that drive the channel. So, when I don't got them, I blab about other stuff. So, feel free to submit them. And if you don't want to post them publicly in the comments, you can send a message to devleader on social media. It's my handle for every social media platform except LinkedIn. It's Nick Cosantino and uh Dev Leader is my main YouTube channel as well. If you are a net developer, you like programming in C#, I have tons of C examples, uh tutorials, things like that. There is a podcast which I already mentioned.

There's resume reviews. So, if you just want to have your resume reviewed for free, you can send it in. I have a backlog of those. I'm going to crush like four or five of them this weekend. Um, we'll do that. It's totally free. I pay for it because I had to pay the editor to do it, but otherwise free for you. And every Monday at 7:00 p.m. Pacific, there is a live stream. And great to see people from Code Commute coming over to Dev Leader live stream Mondays at 7:00 p.m. Pacific. So, topics are usually things from Code Commute. similar topics and we talk through them on the live stream. It's an AMA. You jump into the chat and we talk. Cool. Okay. So, when I was making a video earlier this week, I was talking about um how and why from like a leadership perspective.

And that was, you know, a lot of that came up with slightly different wording this morning when we were recording our podcast interview. And um I think that you know it was really interesting to hear a lot of the same things being echoed back in slightly different ways. Right? So we were talking about this idea of um this idea that if you are trying to lead and um when we talk about leadership by the way I think sometimes people think about well I'm you know I'm just a junior developer like why does leadership matter to me? I'm not a manager or I'm just a I'm just a senior engineer and I have no interest in being a people people manager. Like why does leadership matter? It's a like leadership is this trait. It's not a it's not a role, right? So I just want to call that out.

If you're like, "Oh, this is going to be a stupid stupid talk. It doesn't matter to me." Like it does. Uh if you're trying to grow as an individual contributor, leadership is incredibly important. Even if you're like, "Oh, it's not a technical thing. It's not a tech stack. I don't care." It's incredibly important because whether you want to admit it or not, software engineering involves other people. And the more impact that you're trying to have as an individual contributor, which uh spoiler alert, if you're trying to grow in your career, generally you need to be having more and more impact. And that's going to involve working likely with more people, which means being able to help be an effective leader regardless of your title is going to be very valuable. So, it's something that I would say please don't ignore it because by the time you um are finding like, oh crap, I need to do this.

It's not that it's too late. It's just that you could have been getting a head start on trying to understand this kind of stuff sooner. So uh just a friendly reminder if you are an individual contributor and it doesn't seem that valuable please it is uh very valuable. So the idea of uh telling people how to do things right um exa in an exaggerated sense that becomes kind of like a lot of like a micromanager sort of trait. And when we were talking through this in the interview this morning, I think that it just like reinforced the idea that when you're telling talented people how to do things, right, you tell them how, what ends up happening is that you remove the ownership that they have over that thing because it's it should be up to them to be able to go figure out the how.

If if the words I'm using sound weird, I I what I'm saying is like uh if you are you have a project for your team. Is this person really doing this right now? Let me in, dummy. Just a quick note, if you are exiting a highway, you are generally going to be the person slowing down. If you're the person who is merging onto the highway, generally you're speeding up. So, friendly reminder that if you're exiting and you are trying to speed up to go past the people that are trying to merge on, they're also trying to speed up. You will block them. Don't do that. Let the people that are speeding up speed up and you go behind them. It's simple. Okay.

So people that end up taking uh or the how part right if you have a project and you want a group of people to go work on this project when I'm saying how what I mean is like you're explaining how the problem that is in front of us is going to be solved. Um, and that often means like talking about decisions that need to be made, how things are going to be implemented, right? You're it's all of the the what and how to go solve the problem. And it's a pretty common thing, I think, for many people that feel that they have responsibility over something that they must be the person dictating how even to others. But that's not really the value ad when you're trying to lead something. It's not I will go tell everyone how it works. I'm the single point of failure. Here's how it's done.

There's 10 people on this project, but they don't get an input because I'll just tell them how. It doesn't scale. It's not effective. and you've taken ownership away from people that should be using that as an opportunity for growth. Right? So the people that are now told how how motivated is someone going to be when they weren't part of the decision-m process, their input wasn't, you know, wasn't heard and they're just told, "Here's a set of things, go do it." Right? for what I was saying the other day is more junior engineers that might be okay for them because they're like I'm not I don't know how to go solve this. It's too ambiguous for me. So I do need direction and that's totally fine. Right? I talked a lot about situational leadership the other day. Totally fine in that context. Especially for more senior engineers though, it falls off real quick when you start removing that part that is probably very interesting and engaging for them, which is there is a challenging problem.

I trust you to go take ownership over it and figure out how. So when you were leading things, being able to provide some framing and providing some guidance and some why we're doing it is significantly more valuable. The thing that came up today that I thought was kind of interesting and I don't know if I said it um at all or clearly is I think I noticed when we were talking about leadership we talk about trust a lot right like as leaders uh like credibility and trust you need to be credible to earn your team's trust and your team needs to trust you in order for you to be able to lead them effectively Right? Imagine, you could probably, anyone who's listening to this, you can probably think about someone that you've had to work for or work alongside and like they don't really seem credible.

There's enough things that are adding up and you're like, I don't know, man. Like, I don't think you know what you're talking about. Or you say you're going to do these things and you don't, right? They're not accountable. They're not being a credible person. Doesn't mean they're a bad person. It's just like that's not a trait that they're really embodying. you start to like there starts to be some type of friction where you're like I know you're saying this but like I don't know if I want to do that. It doesn't really make sense to me or I don't believe that's going to happen. It just becomes really ineffective. I'm falling apart here. This stuff stains like crazy and it's all the shaker's dripping everywhere. But trust goes this is the thing that was like a I don't think it's new information for me necessarily but a different way to think about it like trust goes both ways.

So yeah if you want to lead effectively you need to earn the trust of your team but you also need to trust and give them space to be able to go do those things. Trust that they can go figure out the how. Right? You want to support them so that if they need help or they're stuck or they need resources, they're blocked on other people and they're unable to go get their how done that you help them with that. But if you don't trust them to go do their how and have some ownership, then you you're removing this growth opportunity for them. You're becoming a single point of failure. whatever you're doing isn't going to scale. I'm not saying it's not going to work. It's just not going to scale effectively. And that's because you are not leveraging other people probably for where their their most value is.

But it also perpetuates the problem, right? You don't give these people this opportunity. How like how do you expect that you're going to start trusting them? Right? You if you never give them this opportunity where you're like, "Hey, this is a project I'm running. Like, this is the area you're going to be owning and like here's why you need to be doing these things and this is the challenges ahead of us." If you don't give them the space and the ownership because you don't trust them, what's magically going to just give you that trust? Like, there needs to be a little bit of risk introduced there, like give them a chance. And there's things you can be doing to be mitigating that or to make yourself feel more at ease, but ultimately you kind of have to give them the space, right?

Imagine a project and let's take the perspective that like I don't know it's probably easier to take it from the perspective that you're leading the project but depending on you know your your level and role and stuff like maybe you want to look at it a different way but there's a project that you're leading and you have other people working with you if so and so is going to be working on some part so and so is responsible for integrating the database into this application just making up something random And if you're like, well, I don't trust that they can get this done, but you haven't given them the opportunity to demonstrate that. And you're like, I'm jumping to, hey, man, like, so we we have this database. Here's why I picked this one. Here's uh here's how you're going to go set that up. You're going to use this package.

And then uh the way I'd like to see this done is that you're going to set up connection pooling this way. We're going to have a repository pattern here. um you're gonna use this OM for mapping these things and you just go tell them how for everything. Number one, they're probably like, and depending on their level and their experience, more junior people might say, "Thank you. Like, I don't have to go figure these things out." Now, that could be helpful. But for someone who's like, "Hey, man, like I'm a senior engineer. Like, I could also like help contribute to this." um or you know at bare minimum like well why did we pick this database why are we going with that OM why do we want this architecture um that that senior person is probably like well what the hell like what's left for me

to do then like if you already know exactly what you want done why don't you go do it right when you start dictating how then people become disengaged it I think the big challenge is People think that it's helping because you're like, "I've already done the pre-work for you. I'm helping. You know, I I went above and beyond. Now you don't have to worry about this. You can just go focus on getting it done." Yeah. But like that's the kind of people burn out on cuz they don't care. their their motivation in that regard just for like to explain this when you explain all of the how to someone their only motivation for getting it done is like hope I don't disappoint this person with how they wanted it implemented but like I feel like that's like the worst motivation someone could have is like I'm just trying to check the boxes for someone else like why didn't that let someone else go do it?

Because you know if it's not exactly how someone else is asking for it in that context like you're you're basically set up to have feedback that's like oh it's not exactly what I want but that's like what kind of motivation is that? Now imagine the motivation is like hey you're doing the backend database integration for this and like one of the really critical parts is that uh for us we need to have low latency and historically we've seen like when we're building stuff the database interactions happen to be one of this uh these aspects where we're spending too much time. So like really want to make sure that whatever technology you're picking and going with, we want that to be a big factor that you're considering, right? All of a sudden you're understanding, okay, like latency is a big thing. You have some room to go figure things out.

So that's even better. And then you, you know, expanding upon that, it's like user experience for us is like really important. We've had feedback from users that when they're using our applications, like time is of the essence. like they need because of the criticality of the work they're doing, they need a responsive user interface. And that means that we have to be thinking about making sure that we can fetch data fast, we can cache it properly. But ultimately, if we don't have that data pulled in first, like it's going to be a slow hit the first time to get it. We need to make sure that we're minimizing that as much as possible for our users. That's the most important thing. The users work that they're doing is really impactful in pick a field, right? I used to work for in digital forensics. So, it was a really easy sell for us.

I mean, when I say sell for us, I mean even leaders pitching it to me. It's like the investigators are literally helping catch pedophiles. I don't know. I don't know what's a more impactful mission than like trying to help support people do that to catch bad people, save children, right? So there's all the reason why. Go do it, right? Like I'm not telling you how to go do it. I'm just telling you things that are really important for us. Now, if there's more clarity needed, like, okay, well, what kind of constraints are we working within? Great. Let's have those conversations. That's part of figuring out how, for sure. But I don't want to tell people how to go do it. If uh more junior people need the help, then sure, we can go spend time doing that. But it's one of those coaching things where especially when people are more junior, you can show them how, but you want to also teach them how they figure out that how for themselves.

But yeah, that big takeaway for me was like this idea of trust that you need to be giving You need to give space to people. And if you're not trusting them, and I'm not saying I know when I if I say the phrase like you're not trusting them, it sounds like because they must be malicious or something. But it's not I don't mean for it to sound like that. When I'm saying you don't trust people is like you haven't worked with them before. You're not sure what they're capable of and you're anxious about like this thing you own and being responsible for. just got to move over a couple lanes here. Sorry. So yeah, I I I don't think that I was thinking about that the other day where it's like the trust part goes the other direction. Uh and in order to build that sometimes it's about like taking I'm calling it a risk, right?

Like you take the chance on the person like we'll give you this opportunity to try and prove that. And there's different strategies and things you can use to try making sure that you're reducing the risk. But ultimately, if you're not giving someone the opportunity, how are they ever supposed to build that trust with you? Like, do they build the trust by just doing exactly what you say? Probably not, because you can't trust them to go make those decisions for themselves because they never got to do it. You're just trusting that they can follow exactly what you say. And like what? That's why it doesn't scale. So it doesn't scale and then the work is pretty meaningless for that person cuz you've taken away their why. Taken away their why and just given them a how to do it. Now they're just the they cover their eyes and type on the keyboard kind of thing, right?

So anyway, I think that was a cool conversation from this morning. That uh that podcast will be published uh next week. Uh, I'm going to be on vacation uh, Wednesday, Wednesday next week until Sunday or something like that. So, I got to figure some things out. I generally figure out my newsletter stuff on Saturday, like sorry, four Saturdays even when I'm on vacation. So, that should be fine. There's probably going to be fewer code can episodes, but um I think there's a couple things on this trip that my wife's going to be doing um that might be without me, some conference activity. So, she might be doing some things and I might just not be in the conference or something. So, uh I might have some time to to mess around and maybe I'll do a couple code commute entries cuz I'll I'll bring my camera.

But if you're like, "Hey, what the hell's with all the videos? Where' they go?" You do 10 a week and now there's three. I didn't uh didn't disappear just on a vacation, which will be good. Uh this one I will be detached from work when I did my station. I just told people like I'm out of the office, but like I I'm going to literally be physically beside my computer. So if it's urgent and you need me for work, let me know. I do like a lot of security stuff at work. So, it's like if you need me, I'm not going to be like, "Oh, screw Microsoft." It's just like I'm here like if you need me and it's urgent, it's fine. But, uh I also try to set boundaries like if I got to be traveling like with my wife, you know, my that's my time with her.

Um so, it's not a screw Microsoft thing. It's just like my wife is above all other things. So, my station, she was at work. Like, I'm just at home on the computer. So, a little bit different. Um, what else we got going on? I got I I have to get a bunch of YouTube recording done this week. I'm excited. I got some videos. I'm excited to make the the vibe coding one for the code commute landing page. We're going to do that. Um, there was an interesting conversation on testing the other day on LinkedIn. There's a couple of people that were talking about like I don't know. I feel like this always happens. Like people have strong like rules for how they test and stuff and I'm like I'm not trying to say that they're wrong but like I don't know why the hell people have such a strong stance on like like a test like this is just wrong.

And it's like is it because if I feel more confident with it in place like uh pardon my language but like who the hell are you to say that it's wrong then right? you might build confidence in different ways than I do, but so the idea was around um there's some nuance here with uh some somenet words, but um we were talking about testing internals and I think for a lot of people they're like, "Oh yeah, don't test the implementation details." It's not quite what I'm saying though. There's a keyword in C and it's called internal. And internal means that when you are putting code into an assembly, you can't see that code outside of the assembly. So there were some individuals that were saying, well, if it's marked as internal only for that assembly, you're you're admitting that like you should not need to test that, right?

You're writing tests against the behaviors. You marked it as internal. No tests across that. And I'm like, I just I strongly disagree with that concept. So, they were trying to say, well, no, it doesn't make sense. Like, you said it's internal. It's internal. So, I'm like, okay, I'm going to put together a YouTube video that explains why because there won't be a single public API across several um several DLS. And when I say public API, sorry, there won't be a public implementation. And I'm going to show that with a dependency that's downstream, I'm going to say I have a parser that needs to run. I just want to write unit tests on the parser. But the parser is marked as internal because it's only used inside of the scope of this assembly. It's basically invoked three assemblies away through a call stack through a web API that doesn't have a public method.

And the argument that I'm hearing is that no, I shouldn't write tests on the parser because it's marked as internal. And I'm saying I think that's because it's a very good candidate for writing tests against. It's just that it's only used inside of this assembly. The only other way that I'm going to show in the video to go test it is that I would literally have to go launch the web server to go call the API that eventually calls the parser and then I don't even know how I'm going to assert the behavior. So no, if something's marked as internal and it's only accessible inside the assembly, I think there are many valid use cases where you should write tests against it. Different story for private methods. And I would say if you want to test a private method, there's maybe a refactoring you could do to pull it out onto another class.

Now it's a public method and you're passing that dependency in if that's the route you want to go. But man, when people with their rules for testing, I'm like, I don't know how the hell you get anything done. Everything's got to be such a strict rule. But we'll see when that video is out. Thank you so much for watching. I'll see you next time.