200 What Are Some Major Mistakes Developers Make in Their Career?

In this episode, I will cover the seven major mistakes developer make that waste their time and slow down their career. This episode will answer questions like "What are some major mistakes developers make in their careers?", "What are some things that slow down the progress of a developer?", and more. 

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_02 0:26

What are some major mistakes developers make in their career? This is a great topic to cover in today's episode of Dev Questions. So I'm going to cover the seven major mistakes that I see developers make that waste their time and slow down their career. If you're a developer, you're probably guilty of at least three of these things. So let's talk about how to avoid these seven mistakes and speed up your career and not waste your time as you try to progress. So, number one thing, one number one major mistake I see is when you just learn new things. Now, this is especially true when you first start your career because you think that you're only going to build in the new things. But let's use an illustration here that I think will kind of give you a good idea of why that's just not the case and why just learn the new things will really stunt your growth as a developer. In the housing industry, building standards change over time. When I lived in Pennsylvania, I lived in a house that was built in the 1850s. And the building standards then were a whole lot different than they are today. And in my basement, I actually had log beams that still had bark on them. Like that doesn't happen today. We don't just fell a tree and then shove it right into our house. So things change over time. We have new electrical standards, new ways of doing different building materials and new regulations over how we can do things based upon what we've learned over the years. But when those new standards come about, we don't tear down all the old houses and rebuild them with the new standards, right? Like that'd be silly. So my house from 1850, great house, loved it, and we just fixed it and changed it over time, but it was still structurally that house from 1850. It just had new modern things kind of bolted on or you know put into place after the fact. We didn't tear it down and start over because there's new ways of doing things. Well, application development is no different. Focusing only on new things will leave a major gap in your education. You won't be able to work on the systems that were built 10, 15, 20 years ago because you're not familiar with how those systems work. Now you may say, well, I don't want to work on an old system, but that's like an electrician saying, you know what, I only want to work on houses that were built this year. That's great, but you really limited what work you can do. And now a lot of the work that you've you know could do, you're not able to do. And then you say there's no jobs out there. Well, that's because you put a major limitation on your career. So businesses are built upon legacy code. It's the nature of business. It does not matter how cutting-edge the business is, at some point, they will have legacy code. Because even if the business starts today and they start with the most modern frameworks, the most modern systems, do you think it's gonna look like five years from now? It's not gonna be the most modern framework, the most modern system, because five years have gone by and they can't just throw things out and start over. So knowing how to work on a legacy code base and knowing how to integrate new techniques is an important skill to have. It's not just about saying, oh, I'm resigned to working on old code. It's how do you work on that old code and bring new things into it? Just like with my house in the 1850s, it wasn't just, oh, I have to not have electricity because it wasn't really a relevant thing at that time. No, we we had all the, we had, you know, high-speed internet. Well, how? Because we worked with the system we had. I had nice new plumbing, I had nice new electrical, I had a lot of things because we worked within the system we had and figured out how to work with the house to improve it over time with those new skills and techniques while still acknowledging that it's a house built in the 1850s. That type of skill as a developer is really important because you may not have the equivalent of a house built in the 1850s. You may not have a software that was built in the 70s, but you may have software that was built 20 years ago or 15 years ago or 10 years ago, and it will not be cutting edge necessarily. Now, it's great to bring it to that spot. It's great to bring it to the newer technologies and upgrade it, and that's a huge skill for developers to have because you can become the catalyst for helping an organization move forward and improve, but you have to acknowledge that you will work on legacy code. So limiting your learning to only new technologies is going to limit who you can work for and it's gonna slow your growth as a developer. Broaden your training to include older versions. If you're a.NET developer, include the.NET framework and earlier.NET Core things in your learning. Don't just focus on.NET 8 or the coming.NET 9. Focus on learning C sharp, learning the.NET system as a whole, and knowing how to move throughout the different versions of it so that you can work with systems that use potentially some older code in a way that will allow you to be useful to the organization as it is and also helpful in moving that organization forward. So that's number one. Number two is learning only what you need for your current job. So this is kind of the opposite end where you know you get into a job and maybe it is working on.NET Framework 4.8. Well, then you only learn that and you only work on that. That's another major mistake as a developer. So too many people cripple their career by only learning what they need to know for their current job. This is a mistake because it locks you into a very specific type of job. When you try to leave, you'll find there's not as many, you're not as qualified as other candidates. And you'll have to spend a lot of time getting up to speed when you should already be applying for jobs. This slows your ability to switch jobs and endangers your career if you get laid off suddenly. This is a big deal. So I've seen a lot of people that get kind of locked in on, well, I'm busy at work and I'm just gonna focus on this, I'm gonna make my current job better, and that's great. But just focusing on that, you know, professionally is not wise. Expand your knowledge outside of a specific technologies and techniques that your current organization utilizes. That may mean taking some of your free time to learn on your own. Your employer is not responsible for your education. You are. Think of this time as investing in your future. If you don't invest early and let it grow over time, you'll have very little later on when you need it. And in today's job market, the idea of changing jobs is getting more and more relevant to more and more developers because you get laid off, you get, you know, downsized or cut out, and you have to find a new job. And it's kind of too late at that point. It's not too late, but it's it's pretty late to try and figure out then how to add all these skills that you now need to know. Continue to build your skills, invest in you. Make sure that you think about you and how you can be a better developer for the next job, whether it's because you want a pay raise and so you switch jobs, or that's because you don't have the opportunity to stay at your current job and you need to find a new one that can support you and your family. So that's number two. Number three, you're you probably expected this, not practicing. So the first attempt at anything is usually your worst attempt. So if you're doing your first attempt at something in production or in a real application, that's your worst time. That's your worst um iteration of that thing that you've learned. Don't do that. Make sure your first attempt is in a practice environment. Now, you haven't actually proven that you learned a subject until you build something with it. This is something that people make a mistake on as they say, well, I watched this, I know what I'm doing, but I've seen it done. The problem is that usually watching something or reading a book or whatever it may be, usually you see kind of the happy path where things just work. But when things break, what happens? Well, you need to figure that out because you need to go through that to know, well, how do I do this in the real world, not just in a nice comfy demo? And then practice helps you build clean examples for you to validate what you've learned and how to use it. And then that clean example can be useful when you later have to kind of refer back to it and say, wait, how did I do this? Well, you have a clean example because you built something, just a sample. Doesn't have to really do anything except validate what you learned. And then building in production or with a real app without practicing first, it's one of the best ways to introduce major bugs in your code. So this again is another danger with not practicing, because you are making your job harder. You're slowing down what you want to do in production, even though you're trying to go faster. You know, it's it's the idea of racing ahead, but actually instead of being like the rabbit in the race, you're more like a turtle, where you just kind of plod along and and have that steady progress instead of the sprint and get distracted and sprint and get distracted. And so when you're talking about learning, practice feels like sometimes you're not getting something done. But in reality, it's helping you make steady progress towards your goal and it's allowing you to do things faster because you are taking it a little slower, because you are practicing in a safe environment first and figuring out those bugs and making sure you know how things work before you put it into a real application, so that then those bugs don't slow down your real application and cause major problems. So spend time practicing everything you learn. You'll improve your understanding of the subject, you'll validate what you were taught, and you'll give yourself something to look back on when you struggle with that subject later on. So this is gonna speed up your development and reduce the time you spend debugging non-working code in your real application. So that's the reason why practice is so important. That's the reasons why practice is so important. So that's number three. Number four on the major mistakes developers make is learning design patterns before learning how to build applications. And this is one specifically focused on those who are earlier on in their learning journey. A major focus of education is on design patterns. But there's a few problems with this. One, you don't know how to build an application yet. Two, you don't know what problems the design patterns solve. And three, you don't know when the cost of the added complexity of a pattern is worth it. So those three things add up to problems. They slow down your development. Knowing how to build an application is really important because then it gives you that foundation. So learn to build applications first. And yes, you're gonna build applications, quote unquote, wrong. They're gonna be not the best way of doing it. That's okay because each application you build should be a little better than the last one. You learn to identify the mistakes you make and fix them for the next time. This will give you a solid foundation to build upon. Then, when you start to see common needs in your application, you can look for design patterns that fill that need. You see, now what you have is a need, a problem, and you go find a solution for that problem instead of having solutions and trying to find needs to fill with that solution. Okay, there's a difference. It's the, you know, getting the cart before the horse. It's not the right order. Knowing how to build applications is really important first. I see a lot of graduates coming out of college where they know all the names for the major patterns, they have all these different patterns in mind, and they can name them better than I can. And yet they've never built an application. They don't know how to build an application. They know all the quote unquote right things to do in an application, but they've only ever built small little practice ones where they've been led by the hand with their in by their instructor. Instead of saying, hey, how would you start from scratch? How would you build an application? A small one even. How would you do that? Knowing how to do that is super important. It's, I think, more important to do that first before you then get into the patterns and other things that will help you, but not yet. And if you do it too early, they'll actually make things worse. Because one of the things people don't realize when they first start off is that every design pattern has a cost. And if you don't know what that cost is, and if you cannot justify that cost, then you don't know if you're making things better or worse. And so if you don't know and you just say, well, I'm gonna put design patterns in because design patterns are good, right? What you actually do is make things worse and worse and worse. And your applications aren't really functional, they don't really work that well because they are quote unquote right, but they're a mess. So instead of doing that, learn about the cost, the problems with applications as you build them. Learn about the things that you need and learn about the uh areas where things could be better. And then when you start to implement a pattern, you will see the costs that it adds to your application as well as the benefits it gives your application. And then you can successfully weigh those two to make sure that you're making a wise choice. So that's number four. Number five is believing more than you actually, believing you know more than you actually do. So this can take many forms. So let's talk about a few different forms. One, you've probably heard about the Dunning-Kruger effect. So when the Dunning-Kruger effect essentially says that when you first start out learning something, you think it's easier than it is, or you think you know more than you actually do, because you actually have so little knowledge of a topic that you don't know what you don't know, therefore you think it's easier than it actually is. Here's a great example of this. And this is something that you know, you may say, Well, I've never done that. Choosing how big an application is, saying, you know, doing an estimate of how long it will take to build this simple little application. How many times have you done it correctly? And how many times have you grossly underestimated how long something will take? Application difficulty is one of those things where, you know, the less experience you have building that particular application, the easier it may seem. You may say, well, you know what? I'm gonna build a CRM, a customer relationship management uh system, because that'd be a great thing to build. How long do you think it's gonna take? That's gonna take you months, if not years, to build, probably years, uh, especially if you do it on your own, because that's a very complicated system. You may say, well, no, it's not. It's just real simple. It's just tracking people and you know, a couple different uh main categories and trying to track information about it's a lot more complicated than that. The same with a student information system, the same with a lot of these other quote unquote starter projects that people try and say are starter projects, they're not. Because the farther you go down into something, the more you realize just how much depth and complexity there is. And so this is one of those things that when you're a developer, you've got to make sure that you are doing enough research to know what you don't know, to know all the areas that are pitfalls, and to know that you have to learn a lot more than you thought you did. And so trying to overcome the Dying Kruger effect is one of these many forms. So there's others though, like the tutorial scholar. So you watch tutorials that introduce a topic, so you think you understand the topic. This goes back to the practice thing, is that you know you've watched these things, you say, hey, I've you know, I've been I've been watching C sharp you know videos for you know months, and now I'm a C sharp developer, right? No, no, you're not. Because just because you watch something doesn't mean you can do something. And if you're not careful, it becomes entertainment rather than education. Because just watching something doesn't really matter. It's about what you comprehend until you actually use it and can prove to yourself and to others that you can do it, you haven't really learned it. So this is another area where developers can overestimate how much they know. I see this a lot in resumes, where a person will list something on their resume and say, well, I am you know an intermediate level knowledge of JavaScript. And what that actually means is they've watched some JavaScript videos. And when we talk about JavaScript, it becomes very evident that they don't really know a whole lot. In fact, they may not have actually ever built a web application that uses heavy JavaScript or even moderate levels of JavaScript. So that's when you go, hey, maybe you just were more watching tutorials and feeling comfortable rather than actually building something. This is why it's so important to build something. Another way this can show up is the sheltered developer. This is one that can be frustrating at times for me, just to be honest here. Um, but it's one where you make assumptions about how the world works because that's what you have seen, even though you've only seen a few situations. I get this quite a bit. And part of this that's frustrating for me is I've seen a lot in my time. I've I've worked as a developer for over 25 years. I've been a consultant for hundreds of different companies. And so I've seen a lot of different situations, and even I have not seen it all. By far have not. And again, it's that kind of Dunning-Kruger effect where I know what I don't know to an extent, and I know there's a lot more I don't know. But I see people come confidently in and saying, well, this is how this is. And I can list situation after situation after situation where that's not true. But what it is is you get so focused on your narrow worldview and your narrow uh part of the globe, your narrow part of the industry, your narrow part of development where you think that you have a good handle on how things work because you're a senior developer. Well, yes, in your specific situation, but that doesn't necessarily apply to a broader perspective. And so if you can identify that, hey, maybe I am a little sheltered, or maybe I am not as broadly skilled as I could be in even knowing what's out there, that can be really beneficial to your career. Because when you start talking to people, when you start comparing notes with other developers, how often do you hang out with the developers? How often do you have those conversations where you say, What do you do and how does it work? And in being open to the idea that they have differing ideas. That might be as valid as yours or even better. Having those conversations and getting outside of your little bubble will really help your career, allow you to kind of pick your head up a bit, see where things are, and have a better perspective on finding your next job or knowing what's coming or knowing how to take advantage of a new technology. Because looking beyond just your situation will be really valuable. Okay, the next one in this kind of category of thinking you know more than you do is the perfect, and I'll put this in big old quotes, the perfect resume. Um, I get people that tell me I've applied for a thousand jobs, and you know, it's just people aren't you know hiring right, or the recruiters aren't reading the resumes properly, or when it's a thousand times, it's something that you have to fix. I know it sounds harsh, and I know you there is a whole messy situation when it comes to hiring, and I know that it's frustrating, and I know that good people don't get hired for jobs they're qualified for. But at some point, you have to realize there's a common denominator. Okay, and that common denominator is you. So you may feel like you don't need to expand your expertise into other areas because those jobs are just asking for too much, or things like that, where you say, hey, you know, I this is who I am, and you just need to accept that I'm a good developer, or you need to know that that's not how that works. It's on you to be able to learn what people are looking for and learn how to present what you can do in the way that makes sense for them. Because they're not coming to you, you're going to them. And therefore, you need to be able to present yourself in a way that's acceptable to them, that's going to be eye-catching to them, that's going to be that's going to show off what you can really do. And you need to be able to think through am I a well-rounded developer? Being honest with yourself about where am I really? And that leads us to the next major thing that developers do wrong or make a mistake in, and that is not honestly evaluating your own work. And this is going to be really hard. This is something that you don't naturally want to do. You naturally want to look at yourself and see yourself as the hero, see yourself as the one that's doing the hard work, that's that's that's right, that's you know, better than other people. And you want to see yourself as successful. But it's important to be able to have humility enough to look at what you do and honestly evaluate your own work. This is connected to number the previous one, number uh five. Um when you build something, you need to be able to evaluate it honestly. Find the areas that need to be improved. If you look at your application, you think it's perfect or nearly perfect, then you're not looking hard enough. Always identify areas you could do better next time. Because when you do that, then what happens is you do make things better next time. And if you're constantly improving slowly, step by step over time, well, you become a more and more valuable developer. And this applies to your resume and portfolio as well, as we were just talking about. Evaluate how you can make improvements on them regularly. Don't blame the hundreds of jobs you applied for as if they're the problem. Figure out how to make your resume stand out more in that crowd. Again, it's either a hundred people's problem or it's one person's problem. Which do you think it might be? I'm not saying that you're doing wrong. What I'm saying is you can do things differently to have better success. So learn to be your own constructive critic. Your skills will improve quickly once you do. And your resume will too. Reach out to others as well, for sure. But the first step is going to need to be you being able to look at your own work critically without being with a positive criticality, where you say, hey, this is complete and that's awesome. But how can I do it even better next time? What can I improve? What can I change? A developer's mindset, whether it be any of your own work or anything else, a developer's mindset needs to be, how do I make things better? That's what you need to focus on. Not how do I make things cooler, not how do I make things, you know, I don't know, anything other than better. That's your focus. How do I make things better for the user, for how the code process was built, how the code process was deployed, how your resume is created, how you present yourself to employers, whatever it is, how do I make things better? Now, the seventh and last major mistake I see developers making. And this is one that um comes up a lot, and I'm kind of smiling here because I see this a lot on my channel, but focusing on scalability instead of simplicity. And I know I just stepped on some toes, and that's okay because I'm gonna step right back. Um it is much more important to focus on the simplicity of your app rather than the scalability of your app. Now, I'm gonna give you an example here that you may not realize. Um, I've said it on a couple different comments. I've kind of talked about this a few times, but I may have to do a full video just on this. I hear a lot about well, you know, in order to scale, you have to use microservices. Or uh monoliths are you know only good for small to medium sized applications, and really they they don't scale, uh, which is just ridiculous. Um, and this is one of those things where, again, kind of going back to Dunning Krueger, you don't know what you don't know, therefore you think it's easier or you think something's better. Um, Stack Overflow. Okay, this is my favorite example because they publish everything, which is awesome. I can give you a diagram that shows you exactly what Stack Overflow in the Stack Exchange family, how it's designed and how it runs. Stack Overflow in the Stack Exchange system is a monolith. It runs on nine web servers. Yes, you can have a monolith run on more than one web server. We've been doing it for decades. Okay, so nine web servers and four SQL servers. And actually, Stack Overflow itself has a cluster of two SQL servers, two to the four. And of that cluster, one of them is a hot standby. So really, the Stack Overflow at site itself is running off of one SQL server. So that's pretty scalable. The application is a monolith and yet serves 1.3 billion page views per month. 1.3 billion. And yet their response time is really low. I believe it's like 12 milliseconds for the home page and 18 millisecond response time for a question page, like super fast, incredibly fast. And I do all this with a monolith. Scalability is primarily a feature of understanding how to optimize your application rather than the architecture of your application. Now it may seem a little odd, but think this through. Scalability is primarily a feature of understanding how to optimize your application rather than the architecture of your application. If you cannot write a performant monolith, you will not write a performant microservice system. Why would it be different? Why is it that your microservices would be better and more performant than your monolith if you can't optimize the code in your monolith? A monolith is the going to be the fastest way from top to bottom, start to finish for your application, because everything is connected. Everything has a direct connection to everything else. So when it comes to communication, it's all internal. With a microservice system, you're now spreading things apart. You have all the same logic in theory, but yet now you also add in the need to communicate over a longer period of time than you would in a monolith. So you've added more complexity. And now you've added all these different working parts that have to work in concert and yet independently. So you've taken all this, in theory, all the same logic of your monolith, which wasn't performant. And you've said, okay, take all that logic, put it into lots of smaller microservices. So the logic is still there, it's just broken in different pieces, and it communicates more slowly. And you've added a whole layer of communication, things like service bus and you know APIs and GRPC and everything else trying to communicate back and forth with all these different microservices. How is that gonna be more performant? The only reason you might get more performance is because you're throwing against more servers. But the reality is you can take your monolith and put it on multiple servers. So that scalability, it's not really what you think it is. So your scalability is primarily a focus of the ability to optimize your application. If you just try to make your application more scalable through architecture, then you're going to make a major mistake. Okay? So your application will almost certainly not have the scalability needs of Stack Overflow. I love the optimism. I love the optimism of you know what? We need to be Google scalable. Like we need to have the ability to just scale up to millions of people at the same time. That's really optimistic, but for 99.9% of the people, you don't need it. Okay. But what you will have is the need for people to maintain and update your application over time. Everyone needs that. When you build an application, it will need to be maintained and updated over time. Guaranteed. Okay, we don't create applications and then never touch them again. If you do, you've got a problem. But so if we build applications that need to be maintained and updated over time, then a focus on simplicity will have major benefits for every time the application is updated or maintained. Because that simplicity will help people understand how your application works, understand how to make it better, understand how to make your application more scalable. And yet, if your application is scalable first and doesn't really worry about the complexity that adds, well, then what happens is it's hard to maintain. People are nervous to touch it, and it doesn't really scale nearly as well as you think it will. So people are going to read your code thousands of times. The odds your application needs to scale to billions of views per month is very, very low. So thousands of times versus maybe once in a lifetime. I would go the thousands of times first. Optimize for that first. Focus on the thing that will happen the most. Now, that does not mean, and please hear me this, it does not mean you ignore scalability. But what it does mean is you should value simplicity over a solution that will potentially scale larger. So this is where you need to think through how do I write good code, code that is performant, but that is simple. Rather than saying, how do I make sure that if we ever get to the point where you have a thousand developers working on this application and we're scaling out to global scale with millions of people per month or even per week, how do we make that work? Okay. So solutions like clean architecture, CQRS, and mediator are solutions for very specific problems. Problems that you probably don't have and probably won't have. Now, yes, there are applications where clean architecture, CQRS, and mediator are the right solution. But those projects probably aren't yours, especially if you're building an application yourself or with a team of two people or three people. You're probably gonna get to that spot. What you probably need instead is the simplicity to allow your whole team to work on it well. So making a simple app will be hard work. Making things simple is hard, but that's where you're gonna see the most return on your investment. So it's like saying, hey, if you you could either put your money into a savings account where it'll make 0.1% interest, or you can invest in this investment over here and make 10% interest. Which would be the better place to put most of your money? Probably the investment. Now, you know, let's not go into the weeds of well, that's a bad investment, whatever. But just an illustration. So when you're talking about your time, which do you want to do? Do you want to invest in the very, very small return on your investments of maybe someday being a benefit? Or do you want to invest in something where it's going to be a benefit day one and every day after? So that's my list of the seven major mistakes that developers make in their career. And I'm curious to know how many of those mistakes have you made in your career? Start counting them up because we can make these mistakes over time, over and over, even. So I know that I've made my fair share of these mistakes. So let me know what your comment, what your number is down in the comments. I love to hear what your thoughts are on these major mistakes and how you've learned to avoid them over your career. Thanks for listening. As always, I am Tim Corey.

SPEAKER_01 37:15

Thank you for joining us for this episode of Deaf 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 IamtimCorey.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 imtimcore.com and enroll in a course.