The Code Isn't Perfect, So How Can I Let It Go?

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experienced dev subreddit for this topic. And I think this one's interesting because I think uh a lot of people can probably relate to it at different points in their career. So, this person was saying they're trying to learn how to let go. And they go on to explain that by let go, they mean when they're seeing things they they feel like are not perfect, right? they're not uh the design could be better, the code could be improved, the the thing could be optimized, whatever it is, right? Like when things don't feel like they're perfect, how do they refrain from like, you know, constantly being like, well, what like one more iteration or we got to, you know, keep keep refining, keep refining, keep refining. And so I think they were kind of looking for some input on this and navigating this.

And I I say that I think a lot of people go through this in their career because I think people have different like obviously have different walks of life but even how they like get into the industry right so like for example um when I think about when I had started in my full-time professional career after being an intern I remember onboarding interns right I remember onboarding people that were new grads I remember onboarding people that were like master's students and there seemed to like I don't have you know like hordes of data on this and it's not like a peer-reviewed study but just from you know my my lived experience on this one trend that I seem to notice was that um especially coming from school right so if you were a new grad or especially I would say even as a master's student

I seem to notice that there was more focus on like how do I get code these wipers man how do I get code to like this seemingly perfect state like I need to spend more and more time on it to get it try and get it perfect and this is just like one little example right like what this person's speaking about but I seem to notice this trend that uh new grads especially if they had spent longer in school were very focused on like how do I at the code like specifically my algorithm or whatever I'm doing. How do I get this to a point where it feels like it's perfect? And again, I'm like whether or not this uh you know, correlation is, you know, is is a real thing or just sort of like my madeup uh observation. Um that's not really the point.

The point is that there's this there are groups of people um that end up hyperfocusing on getting things to perfect, but it's a bit of a trap because like perfect doesn't really exist, right? Like you can keep trying to make things better, but if we pick anything, there's going to be diminishing returns at some point, right? You could, just to make up an example, right? You could write an algorithm and it might have some type of performance characteristics and it's your first, you know, sort of pass on writing it and you're like, okay, like this functionally does what it needs to do, right? Like it's not it's at least not buggy, right? You have your inputs and outputs. It's tested. Cool. Okay. But like performance-wise in terms of like runtime, memory usage, could it be better? I don't know.

So, like if you were to spend some time on it, look at it, review the code, maybe try a couple of things out, you might go, "Oh crap." Like, "Hey, if we make a tweak here, we can still keep it accurate, right? I'm not regressing the behavior, but now I could squeeze out maybe an extra 20% performance boost." Cool. Okay. So, you go do that. And now, if I were to ask you again, well, could it be faster? Could you do better for allocations for memory usage? Well, I don't know. Like, so give it a shot, right? And so you spend time on it and then you might go, "Yeah, okay." Like I actually can save another, you know, 5% here. Cool. Okay. And then if I just keep repeating this, like the point is that when is it perfect? Because if I keep asking you, can we make it faster?

Can we do better on this? and you keep trying, odds are you will keep finding some way some way to improve it. It's just that there's going to be diminishing returns and depending on what you're doing may have like rapidly diminishing returns. Sometimes it might be like really worth it to keep investing time. But my point is that if you pick anything and you take this approach, you will keep finding ways to improve it. Right. It's uh I've talked about this in the context of uh I mean I've made some videos on this maybe a while ago, but uh shipping software and like when people start testing, right? Like actually getting hands on. So we're on the on-ramp and people are going 40. Got to move. I'm not I'm not doing that, man. We're not going to merge on the highway going 20 m an hour below the speed limit asking for problems.

Um when I've talked about this in previous videos for shipping software, I've said, you know, there were there were times where we would go to have a release. So release is going to go out on some day. So we got to make sure you know all the features like we're feature complete by some date and then what would happen is people would start doing like release testing and conceptually not a terrible idea, right? Like we want to make sure things we have some extra eyes on things before the product goes out the door. Okay. And so what would happen is people would test and then inevitably they would find broken right? And so like Okay. And so as they're testing, it's like, well, we got to start fixing these things and we got to start putting the fixes in. So it's like, you know, bug bug bug fix fix bug bug bug fix fix in like this short period of time.

And what would happen is that people would look at that process and if you were to say, well, we I don't think it's effective that we're testing there. Someone would say, "Bullshit, Nick. Like, look how many bugs we found and fixed." And I'm like, well, I don't disagree that it's finding issues, but I disagree that it's the effective time to be doing it. So, if you need to rely on that period to catch your bugs, you're screwed. It's far too late to be doing it. But the whole point of me using this example here is like say when people are developing their features, right? Like even if they were to have spent a really long time on the feature and it's like it's late because they're trying to perfect it. I could guarantee you could guarantee it at some point in release testing someone's going to find a bug, right?

It's never going to be perfect. And my point in saying this is not to discourage you to say like then you might as well not even try to make it good. Not the point. My point is that it's never going to be perfect. And that means that we basically like this person is saying on Reddit, we have to come to terms with that. It's just it's just like a reality. And I think the most important part is figuring out where to draw the line in what context and then being able to communicate that effectively to the people that are involved as stakeholders. Right? So to give you an example go going back to like an algorithm for something. If someone said hey like does this work and you said well yes it works and they okay well is it tested like how confident are you? Oh yeah like it's perfectly tested.

We got all these inputs and outputs that that match up the way we expect it works. Okay. So depending on who you're talking to the stakeholder things they like they might be totally content with your answer to that. Great. Trust the engineer on this. They say it's tested. I trust they also talked with, you know, whoever they work with on on their engineering team about it, you know, passing QA or other test standards, whatever, right? There's some level of trust. Now, someone else might say, "Cool, like I'm glad to hear that like, you know, the the test and stuff passed the we have the the behavior we expect for the inputs and outputs, but what about the performance?" Right? So, some different stakeholder might care about that.

And that's where you might go, "Oh, shit." like well what was the expectation there like you know maybe we'll go back or you could say actually we did you know we did validate that we actually did a uh the reason this is late to ship or later than we planned is like because we actually went back and did some of this so that next stakeholder might be great like you know I that was you know obviously I want the functional behavior there but you know the performance characteristics are actually something I had concerns about so I feel good about this and depending on what people give a about they could keep pushing back from all sorts of different angles, right?

like, well, did someone do a security audit on this to make sure that there isn't a way that you could have some weird like overflow situation or depending on what part of a system you're building in um you know, someone's able to pass in inputs that could they could have some uh type of uh like mal behavior like something that is not what you're expecting and they could compromise things like did anyone think about that and someone might give a about that, right? And so there are so many different characteristics of what we're building that you could spend an like indefinite amount of time just constantly tuning and trying to perfect something and someone will always be able to poke some type of hole in it. But at some point there is a good enough. And I don't say good enough to make it sound like the bar is set low when it's shitty.

I'm saying good enough because per like perfection is basically impossible. And I think that people need to understand that perfect is impossible and that's okay. And really it's about figuring out what things do we value, right? What things do we value? In what context do we have a different perspective on how much uh those values weigh? Right? So for example, someone might say like, hey, like security is the most important thing, right? And so sure, if you're shipping like live services and someone's reviewing the code and you're having this conversation, security might very well be like one of the most important things that's being discussed. Now, if I had a script that only runs on my computer and it's just like a tool for, you know, formatting my code or I'm just making up some example, but like I just have something that literally runs locally.

It's not a shipped piece of software. It doesn't even connect to other services. Like if that's going into the repository and someone is like, well, you know, how much time did you spend on security related things? And I said, "Well, dude, I spent literally zero zero milliseconds thinking about security because it's not even relevant here." The point is that like how much time effort you spend on particular things that even when they really matter may change dramatically based on what you're building. Okay. So, I'm going to instead of starting to repeat myself more, I just want to like make that point is that it's very much contextual and you know what you're building, the teams that you're on, uh maybe even like a company's culture around certain things, a team's culture around certain things can all influence this stuff. And from individual to individual, people will have different opinions on this.

So I think the most important part is understanding it's not going to be perfect ever. Understanding or getting alignment within your you know your team that you're working on or the stakeholders participating in a project. What's important and then really being able to communicate these things effectively so that people are on the same page so that if there is a misalignment it's not like a surprise. it's hey like we actually said we care about this or if someone's spending longer on something and we go well why what's what's up and they're talking about spending time on something that stakeholders don't actually give a about then it's probably not worth investing more time into and again if there's disagreement on it it's not that that's wrong it's that we should discuss it right if someone's like actually no like I think this is an exception to

the case I think we really do have to spend more time on this particular thing even though usually we say no great let's talk about that why like if you feel so you know passionately about this like let's talk let's understand okay so to this person's question like how how do you come to terms with this the reason I was bringing up the the student versus maybe other hires sort of experience that I had earlier on in my career was that it it just almost seemed like people that had been in industry longer just happened to have this lived experience maybe a little bit more regularly where and and whether or not they felt it was right or wrong I I don't know but um had at least seemed like they were in situations where they're like product had to go out right and like

maybe in some cases it was hey that felt bad we got rushed we didn't get to test things we had a lot of tech debt that was not good right and the I think something that's really hard for people to to get and like this is maybe gonna sound a little controversial, but like that might have been totally fine. Like at the end of the day, uh a lot of the places we're working for are businesses that are trying to make money and they make money by shipping value to customers. And if you felt that the code wasn't perfect or you couldn't write the tests that you wanted to write or the architecture wasn't the exact way you wanted it to be. I get, trust me, I get that can be frustrating. And I say I get that because I love building I love writing code.

I love putting things together. And I am a software engineer at heart. So like even though in my role as a manager, I'm not writing code now. I still build all the time. I really like being able to put together things that I think are well put together. So, I can understand what that feels like to not being able to get there. I can understand what it's like to have pressure to go ship something. Like, if you're like, "Oh, you're just a manager. You're not the one doing this." My dudes and dudetss, like, I spent the first eight years of my management career being a software engineer at the same time. And when it comes to pressure on things, I want you to understand that as a middle manager, I have pressure coming from the top down and I also have pressure from employees back up.

I get sandwiched between it. So, I get what it's like to have hard deadlines and having to ship I understand and I understand that's frustrating. My point is that I think in a lot of these cases where people had sort of complaints about how releases and things went, if we were to step back and look at it from the perspective of the business, from the perspective of the business, it may have been very successful. And that's the part that I think is probably difficult for some people to hear. It maybe is a little controversial because they might say, well, it could have been better, right? Like we had bugs to fix after. Like I get it. Yeah. But uh if you spent all that time fixing those bugs up front or you tried to do all this performance stuff up front or whatever it is, tried to perfect things, would you have even shipped it?

You know, I think this is uh maybe more relevant for startups. Would your company even be here if you didn't get that thing out when it did? Maybe. I don't know. I don't have a crystal ball, but like timing is important. getting out the door is important, right? There might be products even or projects uh at really large companies where uh large companies trying something out, trying to penetrate a new market with something, a new offering, you know, slips by a week, then a month, then a quarter, then it's a year late. There's lots of other companies building right? So like you could completely miss and then all of that could be for not right. I'm not saying that when you miss deadlines it's automatically everything's screwed and it's a waste of everyone's time. Could be lots of great technology, could be lots of good learnings, but that's a really big cost that you could be missing out on.

So, um I I do think that it's really important that that people understand that like we work for businesses, right? If there are things in the process, so you're going through one of these releases or something or a project and you're like, man, like I'm finding it really difficult to like find this balance where I see things that aren't perfect, right? Um, I would recommend that instead of just being frustrated and giving up or, you know, every single thing you try to nitpick until nothing's moving. Uh, I think there's somewhere in the middle that's a good balance. And what I recommend is finding for yourself this balance where if you think that it's going to be absolutely blocking in terms of like the core values of what the team or the the product is, the service, then you might want to raise awareness and and

and kind of align that with stakeholder or team values to say, hey, look, like this here is a security risk and like we should probably close this particular one or like I work on some stuff that's extremely high performance and if someone was like hey code code looks good except like in this algorithm you're doing some things on a hot path that will be allocating and like you could you know flip to a different sort of approach here and avoid that like that might be something in a particular part of code where I would tell people like you should you should gate things on that that's actually really critical for us so I recommend you try finding what those things are and then for the other things trying to find some peace in like taking a step back from it. Raise awareness, right? Don't give up on the raising awareness thing.

That that is important. What's less important is that every single thing that you have to stop, halt the presses, nothing can progress because won't get done. Things have to keep moving. So if you're getting frustrated by the number of things that you keep finding late, I think that's a conversation you need to have with your team, with your manager, with your peers, however it looks, where you're saying like, hey, look, I think these things are important. We keep finding these things late and like instead of me and others, you know, you could if there's other people that feel this way, instead of this being like a pain point later, how do we work to find and address them early? Right. I think a lot of these things become frustrating because they're found later. They're more work to go fix up later.

So, you become a pain in the ass to other people when someone's done a whole design that you weren't paying attention to and then you're check like reading their code and you didn't pay attention to the first few revisions. Now, it's, you know, multiple weeks of like effort put into something. Now, you're looking at it and you're like, "Ah, shit." like this isn't done well. Yeah. Like now now you're it's good you caught something, but you're going to be a pain in the ass. How do we make this better? Let's let's try to find these opportunities earlier. All right. So, I think it's about coming to terms with like not everything needs to halt the presses without giving up on communicating that these things are important and finding ways to to get them done earlier. Um, as I park away if you want to try and connect this back even to like developing with agents because how could we have a conversation without AI somewhere?

I think it's very similar, right? There's some things that I ship that a uh that agents have put together and I'm like it's not perfect, but like passes, you know, the bar that I'm holding for the things that I actually really give a about and for the stuff that doesn't let it in and I will have another pass after to to get things cleaned up and try to come up with some rules to prevent that going forward. So, I don't know. These are my thoughts on this. I'd love to hear from you, especially if you have a different perspective on this. If uh if some of that stuff I was saying you're like, "Dude, I can't believe you would say that. That sounds stupid. I'd love to hear your different perspective, but respectfully of course. So, if you got questions about software engineering, career development, that kind of stuff, leave them below in the comments.

Otherwise, you can go to codecanate.com. You can submit stuff anonymously that way, and I will make a video for you and others to watch. Thanks and I'll see you next