202. 3 Ways Every Developer Fails and How to Avoid Them

What pitfalls should I avoid as I learn to be a developer? What are the things that slow people down when they are learning software development? These are the questions we will 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_01 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:25

What pitfall should I avoid as I learn to be a developer? What are the things that slow people down when they're learning software development? Now, this is the question we're going to answer in today's episode of DevQuestions. And if you have a question, go to suggestions.iamtimcorey.com and ask it there. Now, this sounds like a question only for new developers, people who are learning to be developers, but really this question is much broader than that because every developer should be learning software development. Every developer should be learning new techniques, new technologies, new ways of doing things, and broadening and deepening their skill set to be more and more viable in today's marketplace. So these are applied to every developer, not just new developers. So I think there's three ways that people fail when learning software development. Let's talk about those three ways. Now, failure number one is not learning from your mistakes. This is important. When you are evaluating yourself, you need to make sure you have an open mind and not just say, I did things great. Look at how you could do things better. When you're looking at your code, look at and say, hey, how could I have done things differently that would have had a better outcome? Be objective about it. Don't just look at your code and say, it's perfect. Whenever you look at your code and say, hey, that code, that's perfect, then you're making a mistake and you're not being objective. Because code can always get better. So objectively look at your code, not just find the bugs. I'm talking about how do you look at your code and say, you know what, we could have logged things differently. We could have had a better flow here. We could have had a more simple process. We could have rewritten things to be more streamlined. We could have made different choices in our architecture. Look at your code objectively, because you will not progress as a developer if you can't identify your flaws. Because what are you going to change if you're perfect? That doesn't make sense, right? So if you're not perfect, how are you not perfect? Don't just say, yeah, I'm not perfect, but I'm a really good developer. How? What are the areas you need to work on? Because those are the things that you need to identify in order to grow. You can't just grow by doing the same thing over and over again and expecting to be better at it. Now, yes, repetition is helpful, but it's not going to broaden or deepen your skills. So you need to make sure that you can be objective about your code. But there's more to life than just code. There's the interpersonal issues and overall job issues. So when it comes to an issue that comes up that might not be about code, it might be about, you know, your job or your performance. Don't make excuses when there's an issue. Don't just try to get out of the situation. Don't just say, hey, you know what? There's a reason why it's not my fault. Okay. So maybe you said that this task will take me a day. And then a week later, you finally are kind of wrapping it up. And your boss comes to you and says, What's the deal? Why did you tell me to take a day when it took a week? You could say, Well, there were things I didn't know, and someone didn't tell you about this. And there's a whole bunch of reasons why it's not my fault that it took five days. That's an excuse. What you need to do is evaluate where the problems were. What things did you do wrong? What things could you have done differently that would have led to a different outcome? So maybe you were overly confident in your skills or in your knowledge of the project. Identify that. Because next time you don't want to be overly confident in your skills or in your knowledge of the project. So you need to learn from that mistake. And the only way to learn from something is to identify it. So don't just make excuses. Try to figure out the real root causes and how you could do it differently next time. And if you always find yourself blaming everybody else, you're probably not doing a good enough job evaluating. There's always something more you could have done. Even if you find out that there's a whole bunch of reasons why that took five days that weren't in your control, maybe next time you evaluate that and say, hey, you know what? There's a lot outside of my control. So therefore, I have to put more margin for error in. There's things you can learn even if everything else is out of your control. So also try to find a lesson in every bad situation. Let's just say you get laid off from work. That's a horrible situation. It might not be anything to do with you. Maybe it's just your company is making cuts, or maybe your company went out of business, or lost a major contract and needed to cut a lot of developers. That's a bad situation, and there's going to scramble to find a new job and all that comes with it. And sometimes you fail to find the lesson in that bad situation. You might say, well, Tim, there's no lesson there. The lesson is companies suck and just don't trust them. Well, actually, that can be a lesson. You can learn that it's not your company's responsibility to make your life great. It's your responsibility to do the best for you. And you have to look out for yourself. And maybe that's a lesson you learn is how to better look out for yourself because you can't just rely on the company to look out for you. But it may also be that you learn to keep your portfolio up to date because when you get laid off, you're scrambling to get a new job. And you realize, oh no, my portfolio is out of date, my resume is out of date. I haven't kept up with modern skills. I'm not job ready because I haven't been learning outside of work, all these different things. Well, learn from that. Don't make excuses and say, well, my company didn't train me the way they should, and they didn't give me the time to learn these things. That's an excuse. What lesson can you take away? What thing can you do differently next time so that when this situation happens again, you aren't in the same position? Maybe it's building up an emergency fund. Maybe it's training outside of work. Maybe it is doing projects every fourth Saturday so you have something new for your portfolio. Whatever it is, learn from that bad situation and do something different so you have a different outcome next time. Now, for me, this kind of came about when I was learning how to create and update SSL certificates. Now, for a lot of you, you may not know what that's all about because you've never had to do it. Today, if you push a website up to Azure, you get an SSL certificate for free. So if you have HTTPS and your URL, you have access to that site. But that takes a certificate. Now, Microsoft is creating and maintaining that certificate for you. And other sites do this too. But back in the day, when we were first creating websites, we were first setting things up, we had to generate an SSL certificate from a company, and we had to go through a number of steps: filling out a form, using a command line tool, creating these files, uploading these files to a server, getting down a new file, unzipping it, adding it to a server, and then extracting out a file. It was a numerous steps to get this file created and to get the site set up. Knowing how to configure IAS in order to take that certificate was another step. So all of that combined, it created a process that was annoying, frustrating, and it took two to four hours at least every year. And that's the key here is every year. And so what happened is, you know, I would create the certificate, I'd get it all set up, I'd get super frustrated, and I'd just be tired and done for the day. I just wanted to not think about it ever again. And so once it was done, I'd breathe a sigh of relief and I'd go relax. I would go do something else. I would be done for the day, whatever it was, and that's fine until next year rolls around and the certificate needs to be renewed. Well, then I have to go through that process all over again, and I've forgotten how to do it because it's been a year. So I had to learn the whole process over again and go through that same pain all over again. Well, what that did was it caused pain for four, six, eight hours sometimes, one day a year, and then I'd forget about it. I had to learn after a couple times going through a cycle, wait a minute, I haven't learned from my mistakes. I've done the same thing over and over again and cause myself frustration when what I need to do is take a little bit of extra time on every step and document it. Because at the end of the process, yes, that first time will be longer. That first time will be harder to do, that first time will be a more intense day than it otherwise would have been. But the next time will be a whole lot easier. And you know what? You think four hours once a year, that's not a big deal. That's not a big time savings. Yeah, it's not until it's time to do those four hours. And then you really regret not having that documentation. And you can't go back in time. So instead, do the work now, and then next time it won't be as bad. So that's kind of when I learned that hey, I need to learn from my mistakes and do things differently and do things better every time so that not only does my next time doing a certificate easier, but I can also pass this off to somebody else. So learning how to learn from your mistakes and learning to do things better every time and evaluate honestly your job is really valuable for getting better over time, for growth. So that's uh mistake number one. So mistake number one is not learning from your mistakes. So the second failure, the second way people fail in their learning is by not being disciplined. So when you're learning, you need to be disciplined. So set a time in the calendar. Plan out, schedule out when you're going to learn. Don't just say, I'm gonna learn sometime. Because when you just say I'm gonna learn sometime, it's gonna start out with lots of training and it's gonna end up with no training within a week or two weeks. And all of a sudden, you've it's been six months and you haven't learned anything. And you look back and go, oh man, I've missed so much. Oh man, I wish I was at this level, but I'm not. And the reason why is because you didn't make it a priority by putting it on the calendar. If you say, Tim, I'm too busy to put in the calendar, then what you're saying to me is I don't have time to train. And therefore, I don't have time to grow. And that may be what you're saying. It may be you just don't have time at this point in your life. That can be okay, but what you're saying is, I'm okay with staying where I'm at. I'm okay with not growing. I'm okay with potentially endangering my career because other things are more important, whatever those may be. And there are times when that is true. But if those other things are really not that important, but you just want to do them more, well, that's a problem. Be disciplined. Put training on the calendar, develop a routine. Don't just say, well, I'll fit it in where I can. Again, that means you won't do it. Instead, put it on the calendar and have a routine. Maybe it is before work three times a week. So you leave for work at 7 a.m., then at 6 a.m., start training. I'm not a morning person. That didn't work for me. What worked for me was 11 p.m. until about 1 to 2 a.m. And yes, that's that's hard because I would still get up at 7 a.m. And that that can be rough, but it was what I needed to do in order to move from where I was to where I wanted to be. And where I wanted to be allowed me more free time because I also had more income. I didn't have to supplement with other jobs. And so by being disciplined, by putting it on the calendar, by having a routine, I was able to move from where I was to where I wanted to be. Because goals aren't wishes. At least they shouldn't be, because they're really not. Goals need to be specific, measurable, and achievable. So when you have a goal, you need to identify what you're gonna do, when you're gonna do it by, and what your end result need is going to be. So you need to figure out what it's gonna be and then work towards it, be disciplined, put it on the calendar, make it a routine. So when I was early on in my development career, well, early to mid, um, I had been a developer as a consultant for years. I had worked on a number of different languages, but my primary language was Visual Basic. So this is back before.NET. And so I was using VB at the time, VB6 when.NET came out, but um I had used that a lot. Okay, I used lots of languages for different consulting projects, you know, companies that say, hey, we need this done in Fox Pro, hey, we need it done this in C. You know, I would get those done. But primarily I liked and used most Visual Basic. So when VB.NET came out, I switched over pretty rapidly. And that transition was pretty great. And so that was actually Microsoft's plan, by the way, with vb.net. They really wanted you to use C sharp, but they created VB.net because it was a good way to transition us VB developers over to.NET. So, anyways, that worked, and I moved to VB.net. But I realized that kind of the whole world seemed to move towards C sharp, and C became more and more popular compared to VB.NET. I knew that I needed to learn it. But by this time, I was working as an IT director and I was doing kind of like part-time development. I was doing development when I could, but not all the time. So when I was working on something, I really wanted to be as fast as possible. I had other things to do, I had lots to work on, and so I would just build an app very quickly. Well, how do you build an app very quickly? You use what you know. And so I'd build an app in vb.net, but I needed to learn C sharp. But that would mean slowing down and not knowing how to do things and fumble through things until I figured things out. And that meant a dip in productivity. And so I kept pushing it off because I just don't have time. I just don't have time. And finally, I realized that I need to set a goal to learn C sharp. I need to set a time frame, I need to set a schedule where I can learn C sharp, where I can build applications in C sharp and figure this stuff out. And yes, be less efficient. And yes, it what feels like waste my time building things that I'm gonna throw away just to figure out how this C sharp works. But by doing that and by having that routine of doing it over and over and over again, I was able to switch over to C sharp and start becoming more and more proficient in C sharp. And then I built more and more applications in C sharp and got better and better at it. Well, that's worked out pretty well for my career. But the reason that happened is because I spent the time to do that switch. I knew I needed to do it, but it was actually setting down and setting that goal and saying, yes, I'm going to do it. So that's failure number two is to not be disciplined. Now, failure number three is probably the biggest one. It's the one that I see people fail on the most, the one that even seasoned developers fall back into this pitfall over and over again. And that is not pushing through hard times. The number one way to be a successful developer is to push through the hard times. That's it. If you can push through the hard times, you'll get better. That's Windows updates. So push through the hard times and say, you know what? I am going to do the work. So training, it's not always easy. It's not always finding games and learning new stuff and flashing new things. Sometimes it's that slog of, I don't understand it, go back and do it again. I don't understand it. Go back and do it again. That repetition over and over again until you finally get it. Don't just skip ahead. I had students in my class that would, you know, they would skip ahead. They'd say, Well, I don't understand it, so I'm just going to move on. Well, no, you can't do that because that's foundational. It's what you build upon. So if you don't understand it, don't move on. And yes, I know that means going through that training video a fourth time, a fifth time, building that same app over and over again. Again, building a little bit different app over and over again, eight, 10, 12 times sometimes to figure out why this thing does what it's doing. But that's how you need to push through, push through those hard times because what you will learn in those times will be incredibly valuable for your entire career. Now, another way people fail to push through the hard times is they have a bug in their code and they try to escape. Instead of debugging their code, instead of trying to figure it out, they just go to Google, they go to Stack Overflow, they go to their coworkers and say, hey, fix this for me. Instead of doing that, take the time to work it through. Bang your head against the desk. I know I've done it a lot. But work to not just try to escape the bugs, but instead to learn how to debug and learn how to track down the bug, how to reproduce the bug, how to figure out why the bug happens, how to research the bug, figure it out. Because even if you spend a week on a stupid little bug, which ends up being something simple, if you spend that week struggling through instead of having someone just tell you the answer, then you will learn a lot about debugging. You will learn a lot about tracking down bugs. You learn a lot about the tooling of Visual Studio or VS Code, whatever you're using. Because by tracking down that bug, what you're doing is actually learning new ways to figure out how code works. And that knowledge will be really valuable the next time you're faced with a bug. It will get easier and easier to track down bugs. Now, don't worry, the bugs get harder and harder. So don't worry, there's always gonna be hard bugs. But by learning how to do those things, you will get better and better at the tools, better and better at your process, better and better at understanding how code works. This is how developers turn to senior developers. When you ask a senior developer about a bug, you'll find more often than not, they have a lot of insights about that or a lot of tools for tracking it down. That doesn't come by just watching a tutorial. That comes from hard won experience. That comes from fighting their own bugs and figure out how to conquer them.

unknown 21:59

Now,

SPEAKER_02 22:00

Another way to not push through the hard times is when you work at your first job or even the first part of a new job and you have a hard time because it's not necessarily what you want to do. Maybe it's not a fun job. My first job was all about data entry. And that's not fun. In fact, I had mountains of paperwork, boxes of spreadsheets that were handwritten that I had to put into the computer. And that's not fun. But you know what? By pushing through, I didn't even realize I was doing this. I was just eager to do something. And so I kind of jumped into it. But by pushing through that and working on how do I be more efficient at it, how do I get better at this grunt job that feels like it's unnecessary, even. But by learning how to push through that and keep going, well, I got all my work done and my boss gave me more fun things to do and said, hey, let's start building a database and let's start building an application. And I got to do some really cool things. And that launched my career because I pushed through the hard time. I pushed through the entry level where it's just not fun, or you do jobs that you just don't like. Maybe your first, you know, first few years even at a software development job is just fixing bugs or just doing grunt work in the code. You know what? You're learning something by doing that, and learn as much as possible while doing that. So the way I see that saw this a lot was I used to teach at a college and I taught C sharp and I taught developers or people how to be developers. They started out with knowing nothing about development, and by the end, they could build C sharp applications. And I often I taught the night class, and I often got students that came from other classes. And the way I taught through C sharp was not from chapter one on in the book. In fact, I taught chapter eight before I taught chapter one because I didn't think the book was laid out real well. Chapter one was all about Windows Forms and dragging and dropping, but you didn't understand why things worked. So when I have new students come to my class and they would say how hard C sharp was. They've already tried it once and failed, and they were trying to, you know, get this these credits for this class. And so I'd ask, okay, well, what about this error? And I'd show them an error in Windows Forms. In fact, if you've watched my YouTube channel, um, yesterday's video was on that error. And I would show them the error in Windows Forms where the form designer doesn't even load. And I'd say, how do you fix this? And the answer was almost universally, we delete the application and start over again. That's a horrible way to fix things. That's not fixing anything. That's not learning from your mistakes. That's not pushing through the hard times. That's escapism. That's trying to escape the consequences of that bug. And some people would even delete whole applications that they'd spent hours on because they had that bug. When in reality, it's one line you have to delete. So learning how to push through those hard times and find out why that bug happens and figure out why it causes your application to crash and figure out how to undo that problem, how to fix that problem, that's a really important skill to not just get around, but instead to learn from and spend the time so that when it happens, you know how to resolve it. So those are the three ways that every developer fails and how to avoid them. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 25:58

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 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.