The Gap Between Good Developers and Great Ones

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the experience dev subreddit. This one is a very sort of generic common question around communication. And I think it's really important to talk through this one. You'll see it come up across the channel in different videos, but this is essentially how do you communicate with non-technical stakeholders? So, um you'll notice that I talk about this in a lot of videos because I do think it's really important and I do think it's the the source of frustration for a lot of people and uh communication in general I often find at the heart of most things that I spend time on in software engineering. um like obviously as software engineers we're solving technical challenges but um I find the biggest problems and roadblocks are are honestly just because there's some type of uh failure to communicate effectively. So it's why I spend as much time as I do on it with um with communicating to non-technical stakeholders.

Um the idea that I want to talk about here is that I think there's some more generic frameworking kind of things we can do first and I got to step back uh because I I I feel like if you think about things this way or try to bring them into perspective instead of me saying oh it's like you know step one, step two, step three, this is all you have to do and it will just work. It's like no, let me I want to see if you can think about what's going on, why it's happening, and then you have your own tools you can come up with uh that work for you, right? So, if we just understand this stuff a little bit better uh from from early on, then I think that you can evolve things uh you know for your communication style. So, you want to communicate with non-technical stakeholders.

The I think the biggest challenge that ends up happening is that we're not considering um we're not considering that when we communicate ideas like the responsibilities on us. Okay. So, a lot I think a lot of the time what happens for people is that they get frustrated when they're trying to communicate things and it's like, well, you know, someone's not getting it. Like, maybe it's cuz they're not smart, maybe it's cuz whatever, maybe it's that. Like, it's always sort of outward looking to like, well, it must be them, it must be them. And then you kind of you can give up cuz you're frustrated or whatever. Um but the reality is like when you're trying to communicate information um that responsibility is on you to try and and communicate that effectively. Now don't get me wrong in conversations like the other person obviously when they're communicating back to you has some responsibility on their part to communicate effectively.

But when you are trying to share information doing it effectively that responsibility is on you. Now, we need to kind of think about what your goal is, right? And it sounds kind of silly maybe, but um you want to communicate to nontechnical stakeholders in your situation. What is the goal that you're trying to accomplish? And don't say, well, to tell someone non-technical something technical like not not what I'm trying to get at. I mean, in your conversation that you want to have like why are you trying to have it, right? Is it because you are trying to uh you know explain a timeline and why something's going to take longer? Is it because there is um you know some technical debt that has to be paid down? Is it because there was um an incident and there was some repairs that went in for it and you're trying to communicate that to someone who has to go communicate that to a larger audience.

what what is the goal that you're trying to accomplish with uh you know the communication that you're you're about to have and I think that you want to keep that goal in mind because that's going to frame up you know the topics that you want to focus on uh but one of the reasons why I think this is important is because instead of trying to think about things from your perspective this is sort of the the secret sauce instead of thinking about it from your perspective in all the ways that it makes sense to you, you actually have to do it the opposite direction. Okay? So, when we think about communicating effectively, especially with nontechnical stakeholders, um, if you've seen other videos of mine, sometimes I'll say things like in general when you're trying to communicate to different people, um, and you want to be convincing.

It's like you're trying to sell them on something, which sounds a little uncomfortable. I I realize in software engineering, but you're trying to sell them on an idea, right? When you're trying to sell people on ideas, what you're trying to do is focus on the things that they value. Okay? So, in this case, when you're trying to communicate something to nontechnical stakeholders and I was saying, make sure you keep your the goal of your conversation in mind, instead of thinking about all the things that you care about, what are the things that they are going to care about? You need to look at it from the other side. Because if all you're doing is trying to find more evidence that convinces yourself or explains it to you, it's not going to help if they simply do not understand it. Right?

And then you will continue to get frustrated cuz you're like, "Well, here's one more thing and here's another." And they're like, "I just don't get what you're saying." Um because the information is just not being conveyed the right way. All right? Right? So we have to think about and this is you know if you spend more time with different people with different roles right so let's say you've never worked with a project manager or you've never worked in a product manager or you've never worked with the UX designer all of these roles have you know generally different things that they they care about. There's commonalities of course like you know you would hope that every single one of them cares about the customer for example but they're going to have different things that they focus on. And of course the more time you spend with individuals the more you learn about how they communicate things that they get caught up on things that you uh you can see that they gravitate towards.

So like an understanding of people and spending time with people is so critical in software engineering and it's just like people I I get it like we want to focus on code but man the more time you spend like peopleing the the more effective communication can become. Okay. So we need to try and understand what other people care about so that we can make our message align with that. is you want to think about what the goal is of your conversation and thinking about it from the other side. Okay. So, um let's use a random example I I had mentioned. Okay. There was there was an incident that you were uh helping do some repair items for. Okay. So, something happened with your product or service. There was a bug. Um and in order to, you know, address that, things were mitigated. There were some, you know, there was some code fixes put in.

And this could be, you know, any number of things by you, people on your team, other partner teams, but you as the software engineer, you were involved pretty heavily in in the code changes, okay? Or around other people that were working on these things. You have a good understanding of it. And now you're about to have a conversation with someone who is uh certainly not as technical. Maybe it's your your engineering manager. Okay. And so it's not that they have zero technical understanding, but certainly the level of depth compared to you as a software engineer and maybe your peers is less. Okay? And they weren't involved directly in the changes. So they're even more removed specifically from that. So you need to communicate this to them not just because but because they're in a position now where they have to go represent your team in a conversation with other stakeholders.

So uh because of this incident there was visibility to you know to their managers their skip level managers like people in higher up leadership positions. Now, this is a double whammy because um the reality is the more likely the more further away you are removed from the thing, the less information the details help with. It's a generalization for sure, but if you think about it, like just to use code as an example, if I had to go communicate up to uh you know an executive level person the impact of something, I'm probably not talking about line 37 if statement to them the class that was duplicated that had the bug fixed, but this one didn't. Like, probably not because they would have no idea what I'm talking about and they wouldn't give a So in this case, this example, it's a double whammy because you

have to communicate this to your manager in a way that they're going to understand and also arm them with enough information that they can go communicate that yet another level of indirection away. So when you're thinking about this like what's the goal? Well, the goal is to enable them to provide um and it depends on what the conversation actually is to provide confidence to leadership people or someone in an executive position that uh this issue has been addressed, right? Maybe maybe those executives are in a position where they have to talk to customers about it. Okay? So, we have to kind of think what is our goal, right? It's to be able to communicate. In this case, let's say that there is confidence that this has not regressed. Uh you know that we have safety measures in place. This kind of issue will not happen again.

Okay, that's the goal. Now, we have to think about not just from our own point of view. Oh man, I put the unit tests in place. There's more integration tests. I put this monitor over here. Like there's no way it's going to happen again, right? like um I'm just you you can go through the list of all the technical things you put in place and at some point you know when you're talking to your manager what are the things they're going to care about? Well, they might understand that there was some code duplication or they might understand that we didn't have test coverage or something like that. Uh and they might even know the parts of the code maybe they worked on it before. So you can get away with a little bit of that, but because they're a level removed, you have to again think about what is it that they care about in their role, right?

They want to understand that like systematically some things are in place. They want to understand that, you know, the technology that you have access to you is is being leveraged. Okay, so um cool there were gaps in the testing framework. I don't care that you added, you know, three tests here and four tests there. Like there were gaps and you added more tests. Cool. That was missed. Why was that missed? Um, we don't have code coverage tools or um I don't know, maybe the tests were there and like the test project was accidentally turned off from running in CI/CD, whatever, right? Um, they won't need all the specific details. They want to know that you got tests in place.

uh if you have monitoring and alerting okay is there information being reported out cool there is they don't need to know the exact like configuration of that monitor or um you know maybe something that is interesting is like maybe there's a I've seen this literally come up in conversations where the threshold of some alert was really the thing that caused us to miss an issue that otherwise would have been detected. So sometimes you can call out like a very specific detail because it's the smoking gun. And I've even seen that in executive conversations where it's like look like we had we did have all of the right things in place. We did have the test coverage. We did uh you know deploy a change slowly. We did have the monitors. It's just that this one particular monitor had a a wrong threshold on it and that's why we missed it until there was enough traffic.

Boom. Right? I've seen things like this happen and it's okay to talk about a very specific thing that might be a little bit more technical because it is the smoking gun. Okay, we got to people, we got to figure this out. What are we doing? You can't go slow in the fast lane. This happened yesterday. I'm trapped in this lane. Someone's got to move. It's me, I guess, because no one else is one more. So frustrating. Okay. Um, so try to think about what the other person cares about to align it to them. And that's exactly what your manager is going to have to do when they're relaying this information to the next audience, right? So the more levels of indirection there are, the more uh sort of translations you have to end up doing. So in a situation like this, maybe it is helpful to give, you know, even more information to say like your manager in this example because now they have more things to kind of play with to tell a story.

So if the framing of this is making more sense, right? Or maybe this is something you already understood. Maybe it was helpful to kind of just hear that this is, you know, uh some an example framing. What do you like? How do you actually make your specific communication more effective? I think one of the best ways to do this is through um through metaphors and comparisons, right? Like this. I'm not a not a psychologist and I don't know uh why this seems to be effective. I don't have obviously I'm driving a car and I can't just pull out, you know, stats out of my pocket and show them to you. Uh and I don't even know if they exist. they probably do, but um using metaphors and in comparisons is supposed to be like an extremely effective way for communicating ideas. And I think it has something to do with um I don't know like our brains understanding patterns, right?

So, if you can when you're trying to explain things to people, if you're like, "Well, Nick, I'm struggling because, you know, I don't know how to to communicate something that is technical without talking about the technical details." Um, try using metaphors and comparisons. So if you can think about examples that other people should understand because of their role, their expertise in an area because you happen to know them as a person and you're like, "Oh, they have a hobby like this like and I can make a comparison to that." When you can explain things through comparisons in ways that other people know like the thing that you're trying to walk through, um it can really help uh like illuminate what you're talking about because now they can think about the frame of reference and something that they totally get. Right? So, I want to think of an example that's not I don't know like super obvious.

uh make it a little bit more challenging for myself to do on the spot. I'm trying to I want to use like a UX designer as an example. Um and you're trying to tell them that okay, maybe let's do this. So you have a UX designer that's like, I want to I want to style some screen or some workflow some way. And you're not disagreeing with it, you know, fundamentally. You're like, that makes sense. I can see why. But what you want to tell them is like look that's going to be extremely complicated to do. Um because and one of the issues is how the code base is currently set up. There's a lot of duplicated code or you'd have to go touch, you know, a bunch of spots to go make this happen. And from their perspective, they might be like, I don't get I just don't get why that's a problem.

Just go make the changes in those spots. And what you could try to do is maybe communicate back to them like, okay, imagine you had all of these designs that you're working on, right? you have all these designs and um so you have them drawn up in whatever tool and maybe I'm sure I don't use design tools but maybe a lot of good design tools allow you to have reusable components and you're like hey when you were making this workflow right like you you were able to go and like drag and drop these pieces on from from this library of like buttons and stuff that you've already styled and all that and they yeah yeah okay and you're like okay cool now so imagine in this scenario though that um you don't have that library of buttons and um and now I was asking you to go change every button to have uh round corners, right?

They would say, "Okay, well, yeah, it would suck because I'd have to go clicking through all these, you know, different designs we've put together and and do it per design." You'd be like, "Yes, like that that is what I have to do, but in the code now." Um, and furthermore, you know, uh, you know, you as the designer might have a list of all the designs to go click through and make sure you get them. And like maybe in your situation for your code, you're like, I don't even know how we go find all of these. Right? So, you can use a tangible example for them where they're like, I can relate to that. I can understand that. And then you can mirror that over to what's actually happening. So, um, using this kind of approach can be really helpful.

But like it's tricky because as you saw even for me driving and talking about this example, I had to I had to come up with something that would be relatable, but this can be really really effective when people are getting stuck on uh on some ideas. So anyway, I'm at the gym. There's a lot to talk about in this. So, I would say if you thought this was at least interesting, you're like maybe you want more out of out of a conversation like this, think about some scenarios that are specific that you have, feel free to leave them in the comments and say, "Hey, how would you approach this specific communication situation or write it in at codecute.com and I'm happy to try and like dive into more of the specifics." Talking about it generically is kind of tricky, but thanks for watching. See you in the next one.