061 How Important is Attention to Detail as a Developer?

How important is attention to detail? Can developers who are not detail-oriented really succeed? Can you learn to be more detail-oriented as a developer? These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_01 0:25

How important is attention to detail as a developer? This is the question we're going to tackle in today's episode of DevQuestions. And I'm going to give you the answer right up front because there's more to tackle around this question. So the answer is it's very important. And I'm going to explain why, but then once we explain why it's important, I want to talk about how you can work on your attention to detail. And then if you're just not that good at it yet, what things you can do to kind of help you out in your attention to detail. So let's talk about why attention to detail so very important as a developer. Computers are logical. Computers don't assume. Computers don't guess. Computers are ones and zeros that operate that way. They do not make assumptions. Now we'll skip the machine learning AI stuff that we're working on. But in general, computers don't make assumptions. They just do what you tell them to do. So as a developer, you have to be very specific about what you tell them to do. Now, it's typically not the major things that you miss as a developer. For instance, if your boss says, I need these three forms built, and you build two of them, that's pretty obvious. You missed one. And that's not something that normally would go to production. Normally a boss come back and say, You're missing one, fix it. Go do that. That big piece that you didn't do, do that. And so that doesn't often get to production. You're not going to find a customer calling you up and saying, Hey, there is no edit my account page. Or there is no sign up page. Usually those things are caught before they go to production. And when an issue is solved before it gets to production, that's a good thing, and it's something that the end user doesn't see. It may take longer to get a new version out, but that's not a huge deal. So the big issues, the big things that you miss, the big things you fall down on, those are problems that need to address, but they're not the biggest problem. The most major issues come from the minorest of oversights. Big things happen because of small little issues. I'm gonna give you an example from this past week or so. Uh Chrome put out a new update to Chromebooks. And this new update was patching some different things. And once this update rolled out, which it did so automatically, meaning you didn't have to say, yes, update my Chromebook, it just did it. And when it rolled out, you could no longer log into your Chromebook. And after tracing down the issues, figuring out what the problem was, the actual patch was to fix one character. One character took down all the Chromebooks that this patch got installed on. And the reason why is because in if statement, instead of having two ampersands to indicate a logical and, it had one ampersand, which indicates a bitwise comparison. So that difference was a big deal. It changed fundamentally how that if statement worked. But it got to production because it probably passed all the unit tests. It was actually an integration problem, most likely. Um, but even that, it was just a little thing, a minor thing that got to production. Now, normally, not being able to log into your application, that's a something that shouldn't caught in testing, you would think, but it didn't. Um, but it was a minor little thing. And that took down things across the country, across the world. I'm not sure how far it went out, but it's a big deal. So that one character issue is a big deal. That attention to detail, because the compiler said, yeah, you can do that. So it wasn't like the compiler had a problem because it's a correct way of writing C. It was allowable to have a single ampersand. It just wasn't what the developer meant to do. So that's where even the tooling wasn't gonna find it because it was a minor little thing and it was valid syntax. Those minor things are what cause major issues because they often aren't caught. Now, some of them aren't quite as obvious as this, some will be in production for a while, where maybe you don't know there's a problem until something happens. It's kind of too late. This is one of the reasons why, and we'll talk more of this later, but this is one of the reasons why I talk about entity framework and the dangers in it. It's not because entity framework is bad. In fact, it's a great tool. The issue is you have to have an understanding of all of the details that you have to do in Entity Framework in order to get it right, because it will work without covering any of those details. You can use none of those details, you can tweak nothing and get it to work and get it in production. But at some point, and this is where it's really um hard on developers, is it's going to break at some point down the road if you don't look out for those details. Things like making sure that your sizing is correct on columns and making sure that you don't pull down too much data and all the rest. Those little details will be fine for a scale up, but once you get to a certain size, they're going to cause slowdowns and other issues. And those minor details are going to be major issues for you. So it's very important as a developer to be detail-oriented. Now, you may be thinking, yeah, but Tim, I'm not detail oriented. Does that mean I won't be a good developer? No, that doesn't mean that. You can fake it and you can learn it. Those two things do work, I know, because that's me. I am not detail-oriented. I am just not. I don't see details often. And so when it comes to my the rest of my life, I have a hard time with keeping track of details and and making sure I get all the details right and thinking through all the details. That's just a struggle that I have. In programming, it used to be a massive struggle for me. But I have learned to train myself to be more detail-oriented in code, but also I put a lot of things in place so that I can fake detail-oriented. Let me explain what I mean by faking it. If you have an if statement and you say exclamation point and then the variable, so exclamation point is alive. What does that mean? It means not. So is not alive, which means that person is deceased. But that little exclamation point is really hard to see. And so you're reading through code, it's hard to notice it. And you may skip over, oh, is alive is true, therefore run that code. And then we go, well, that's not right. And you go back and think, oh, there's an exclamation point there, got it. It's not. Okay. That little detail can trip you up. And especially in things like if statements, which is what that Chrome issue was, um, those little details are important. So there's an there's a knot in that Chrome statement um that wasn't the issue. I wondered if it was, but um it could be looked at and missed if you're not careful. I read through it, I'm like, oh wait, wait, wait, there's a difference there. It's not okay. So what I do to help myself out is I make the detail more obvious. So I say equals false is alive equals false. Then the detail is more obvious, it stands out more. So when I'm reading through code, when I am debugging in my head, when I am evaluating the code, I can more easily see, oh, that saying is false. I don't miss the fact, that little exclamation point. So looking at those little details, I make them bigger in some way. I try to make sure that I don't make mistakes that way. With if statements, another thing you can do is in C sharp, you can have an if statement that does not have curly braces. Instead, the next line will be the what would be inside the curly braces, and the line after that does not apply to the if statement, it'll get run every time. I don't do that. I always use curly braces. And the reason why is because if I tab the next line over, then I would assume just by reading through it, I'm like, oh, those two things are under the if statement. Or may I put the next line in there and go, they're both under the if statement. It's a detail, it's a small thing, and it's easy to miss. And so I say, nope, I am not going to allow myself to have that potential tripping point. I'm going to put the curly braces in. It's two more characters, and with those two characters, I get some peace of mind that the details are bigger, that I can see more easily and be able to check, oh, that's a problem. Okay. Another thing to think about entity framework. I'm going to go back to this again. Um, entity framework. There's a couple of details in there like to list. If you use to list, you kind of defeat the purpose of entity framework in a lot of situations. Because what it does is it doesn't run the query until you need it to. But with to list, it goes, oh, no, you want all that data now. And if you're not careful, you can pull down too much data too fast and not rely on some of that lazy loading, waiting for the data you need, waiting until the correct uh filters are in place, and so on. So little detail, big results. The problem is that when you're in development, you're not gonna necessarily see that as a performance hit. It's only when you have enough custom records or other records where that that that record set grows, and all of a sudden, now instead of taking you know 0.2 seconds to run, it takes two seconds to run. And you're like, that's odd, it's a little slow. And then down the road another year or two years, all of a sudden it's taking four and five seconds to run. You're like, that's not right. It's that little detail that not only caused a problem, it caused a little enough of a problem that it was something like it could grow over time and suck the resources away from your application, take time away from the users, and just give a bad feel for your application slowly over time. So that little minor thing didn't cause a massive issue right away. It was something that just slowly leached off your application. That's a detail that was important that you missed. Okay. Um, not putting a WHERE clause on your search before you pull it down. That's a detail that, again, when you have 10 records, 100 records, a thousand records, not a big deal. It's when you get a million records that it becomes an issue. So those little details can be an issue. This is another another reason why I like to use store procedures and Dapper. And this is not about EF versus Dapper. Uh, both are good options. But for me, what it does is it allows me to more easily see what I'm doing. Because I can run every store procedure in SQL Server. I can run it manually and go, okay, that returns two records. Cool. Or, okay, that just returned every record. That's a red flag for me. Let's even change that. And I do it right in SQL Server so I know I can run it multiple times. Trying to run entity framework queries multiple times can be a little trickier, and often people skip that step and they don't test those things out. And so they miss those little details. By using store procedures, I have made it more obvious and bigger what the issues could be. I've made it more um, I've exposed my potential details and made them more clear. So sometimes I'm kind of filled in the gaps by doing that, where I say, you know what? I'm not totally detail-oriented, I'm not catching every single character on the screen. I may miss little things, but if I have certain habits, I can kind of fake it. Where I put things in place to help me make sure that I meet that detail-oriented uh bar that I have to meet in order to make sure that my code runs well. So detail-oriented is very important. Detail-oriented with a difference between being a good developer and not being a developer anymore. Being detail-oriented is the difference between having an application that runs in production for years or decades versus an application that's constantly having problems, or even worse, problems that occur years down the road that cause massive issues. Okay, so details are important. Not everyone's detail-oriented, who's a programmer, but there are things you can do. Another thing that I do is when I copy and paste, when, if I copy and paste, that's the first step. I avoid copying and pasting. I do it in the videos sometimes. I try and tell you, hey, I'm gonna copy and paste here because it's quicker, but it's dangerous. Because the reason is you're gonna copy code that's working, and you're gonna paste it down below in order to change all the values. But if you miss one value, then it's still working code, which is the worst kind of problem. Because it will go to production working, just not working the way you intended. That's a big problem. So you want to make sure that you avoid copying and pasting if at all possible. It's okay to retype some things, it's alright. Work on typing. We're gonna have to do it all of our life, anyways. Save yourself some potential bugs, save yourself from missing small little details. That's one way of doing it. But if you copy and paste, what I do is I double check things. So I go through every single line and read over it and make sure that the details have been changed in every single line. Yes, that takes extra time, but that extra time is worth it because more often than not, I find one little detail that I missed. And because I found that detail, I found a potential bug and fixed it right there. So I can kind of fake it at the same time, and that's through discipline, but at the same time, I can also work on practicing that that concept of being consistent, practicing that concept of reading over my code, not just skimming it, not just assuming, oh yeah, that that does this. No, no, no. Work through the logic and make sure the logic matches what you think it should do. Okay. So there's ways to practice it, there's ways to grow in it, there's ways to fake it, but you have to be detail-oriented as a developer. All right. So that's the answer to this week's question, this week's dev question. I hope you enjoy it. If you're looking for more answers to your dev questions, look back at the archive. We've got uh 60 or so episodes at this point that um will answer your questions on a lot of different topics about being a developer. This is both a podcast, you can go to your favorite podcast player and find this podcast. But also, it's on YouTube as a series of videos. Check out either one, and thank you for listening to this week's episode.

SPEAKER_00 17:52

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.