294. How Do You Protect Your Career from AI as a Software Developer?

Everyone says AI is taking jobs. Can I still be a developer? Are there some programming jobs that will go away because of AI? How do I ensure I keep my job? 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

There's a lot of uncertainty in software development right now. People are concerned that AI might take their job. They're concerned there aren't enough developer jobs to go around. And they're concerned that the hiring market is broken, amongst other things they're concerned about. And I think that people have a right to be concerned. But I also think that now is a great time to become a software developer or increase your skills in software development outside of just using AI. You just need to make sure that you protect your career. Let's talk about it in today's episode of Dev Questions.

SPEAKER_00 0:42

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:46

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to protect your career as a software developer. And let's start with the basics. AI will be taking some jobs from people. In fact, if you aren't careful, your job may be in jeopardy. But it isn't because AI is doing something amazing or that it can do a software developer's job. It isn't, and it can't. Instead, what it can do is make you bad at your job. So let's talk about how. First, software developers solve problems. We don't just write code. And if you think that writing code is all we do, and that's all you can do, then yeah, you're in danger because you kind of miss the point of being a software developer. A software developer isn't just told what to do and then do it. Say, here's the bugs, fix the bugs. Yes, sometimes our job ends up being that, and we kind of just focus in on that. But really, a software developer's job is about figuring out how to provide value to the customer, figuring out how to accomplish a goal typically through code. What's the difference? Well, even if you have AI writing code, what code is it writing? How does it know what to write? How does it know to write the right code? How does it know what decisions to make? That all comes from somebody telling it what to do. By somebody saying, here is a specification, here is what this should do, here's the guidance for doing this. And yes, it needs a lot of guidance because no, AI is not a thinking process. It does not evaluate in the way that we think about evaluation. It doesn't make good architectural decisions on its own. It needs to be guided in how it does things. So if you're just here saying, I write code, well then yeah, AI is gonna write the code now or some of the code, especially if you let it, because when you say, hey, you just write this code and then ignore what it does, well, that's gonna be a problem. You're gonna find yourself not doing a good job as a developer. Along with this, developers are bad at code reviews. This is something that has way before AI. This is something that developers have struggled with and something that there have been studies on and people have observed. And that is when a pull request comes in and you're assigned a pull request, if that pull request has one file changed and a dozen lines of code, more often people will very closely inspect those 12 lines. They'll think about it, they'll evaluate it, they'll make sure that you're making the right choices, and they'll give good feedback. However, if you turn in, let's say 10 files changed and a thousand lines of code changed, more often those pull request reviews consist of sounds good. Yep, I think so. Is it pass a test? Good enough. Where the developer reviewing the code didn't actually do any evaluation because he looked at how much was changed and went, that's a lot. I'll just skim it. And they don't actually do a thorough review. And that's just human nature. It's it's we look at something and say, that's overwhelming. I'm gonna spend an hour or more reviewing that code, and I don't want to do that. And so often, you know, pre-AI, those reviews were skipped or they were poorly done. They were, you know, nitpicks were made, but no actual content was thoroughly reviewed. And that can cause problems in a code base, which is why we say make small pull requests, make small changes rather than massive changes all at once, partly because it's easier to manage in our heads, our context window, but it's also easier for reviewers to understand what we did. And it's easier to say, hey, this chunk didn't work, let's roll just that chunk back as opposed to the entire thing. Here's the problem. AI doesn't do that. By default, the way AI will work is it will run, rate, write hundreds, thousands, tens of thousands of lines of code to address a problem. And the more it does that, and the more you just start rubber stamping things, the worse it's gonna be. Because now, what's your point of existence? Why do you exist as a developer if you're just gonna say whatever the AI says is good? Because it's not, I can tell you that. The AI is consistently writing bad code, not all the time, but consistently. Meaning there's gonna be a little bit of bad code pretty much everywhere. You need to figure it out, find it, and change it. You need to make sure that you review it and make sure that the AI is being consistent and how it's doing uh rules and how it's using code and how it's reusing libraries and other code you already have in existence. There's so many things you need to do. So you need to make sure that as a developer, you are working on being better at code reviews to actually review what the AI does. Now, with this, the more you rely on AI, the less you remember. It's like working out. If you watch people work out, that's great. Maybe you'll see a better way, a better form or something else. But until you actually lift the weights, you're not building muscle. So when it comes to development, if you're not actually doing the work, you're gonna start have seeing atrophy in your areas of software development. Uh, a great example of this, if you've watched the movie WALL-E. Um, it's, I believe, a Pixar movie. And in the future, people leave Earth because Earth has been trashed, you leave a little robot behind, whole nother thing. But if you watch the movie, you'll see that they have this progression where people start off like we are now, and they eventually end up living on these hover couches overweight and can barely do anything. They can barely walk, they can barely stand, because of the fact they allowed more and more of the work to be done by a robot. Well, that's kind of where we're at with AI, where the more and more of the work you allow the AI to do, the less and less skilled you will be if you don't continue to work out yourself. So relying just on AI to do your work is going to mean that you're gonna atrophy in the areas of actually being able to do the job yourself. So I think what I see people doing is they stop learning. They stop practicing, they stop making sure they can do the work and they just allow the AI to do more and more of the work. The problem is the AI doesn't do good work. And I always hear people say, well, but it will in six months. The next version of this next LLM will do a better job. You know, there's all these code quality tests that you know, Claude or whoever else has passed, and it's so much better than developers. No, it's not. It is not perfect. It is not good enough, even. And it needs to be guided. And so the more you rely on it, the more you're going to have bad code, and you also have less and less ability to remember how to fix that code. So make sure that you are practicing. And then don't stop learning. People stop learning and start depending on the AI because why would I learn when the AI can tell you what to do? In fact, why would you learn from an AI? I've had people tell me, well, I'm just gonna learn from the AI. What's the point? Because the AI is confidently wrong some of the time. And so you don't know where you're starting to add potholes in your memory. And the thing is, people say, well, but everybody's wrong sometimes. Yes, but the AI is confidently wrong enough, consistently enough, that you are, you know, maybe only 10% now, but that 10% plus the next 10% adds up over time. Before you know it, you have 40%, 30% actual confidence in your skills. You have so many gaps. So don't stop learning because you'll start depending on the AI. Now, the end result of all of this, when you say, you know what, I just let the AI write the code. I don't really review it real well, I don't practice code development, and I have stopped learning new software development and just focus on the AI. The end result of all this is that you're an auto-approving AI jockey who has no real value. Because if all you're doing is saying, hey, do this, then if you've ever watched the movie Office Space, there is the guy that comes in to talk about why he justifies his jobs or his job. And he tells the reviewer, he said, Hey, I take the information from the customer and I give it to the engineers. And they're saying, Oh, so why can't the customer give it to the engineer? And he's trying to justify why he needs to be in the middle. And in fact, it's not actually him, it's his assistant, and that his assistant's actually just taking a fax and give it to the engineer. Like we have bowl it all down, there's no reason for his job. And that's where you will be if you're just an auto-approving AI jockey. Because what's the point of having a developer, a highly paid developer, in the loop if they're just going to approve what the quality assurance person could have told them needs to be done? Why can't the QA person just say, hey, AI, build this? Right? So if there's no added value, then what's the point? And the more you just rely on AI, the less added value you provide. And this is where I think there's a big deal coming in the industry where there's gonna be a lot of people who think they're developers, who even have years of experience as developers who can't do the job. And that's a real uh opportunity for people who are willing to do the hard work. So what should you do instead? What can you do to make sure that you protect your career, to make sure that you aren't just falling into this trap of being like everybody else and slowly having your skills erode? Well, number one, deepen your skills in software development. That doesn't mean learn more AI. We'll talk about AI in a minute because it's not something you ignore entirely. But instead, deepen your skills in software development means learn more about your primary language. For you know, this channel I teach C sharp, and I teach people go deeper into the language, learn more about, learn more at the nuances about how to understand and understand the trade-offs, understand how it works so you have a better understanding of what the choices are that you have when it comes to building an application. You have more tools in your toolbox, deepen your skills, and with that also broaden your skills. Add more skills where you know more about other areas and know what the alternatives are. Now, number two is get better at architecture and code review. Understanding how an application should be built, how it should be designed, how it should be structured is important. Knowing how to put all these things together, knowing how to connect the pieces is important. Knowing how to look at a situation, evaluate what might need to be done, what does need to be done, evaluating what's important and what's not, and then evaluating how to take code and other things to solve those problems is really important. But with that, also code review. You see, like I said before, being good at code review is always a struggle, even before AI. If you can use this opportunity where AI is writing more code to practice and build your skill at code review, learn to be better at it. You have lots of opportunity right now because the more AI writes code, the more opportunity you have to review someone else's code, the AI's code. So learn to get better at it, learn to move beyond just rubber stamping things and evaluate what every line does. Understand how your code is structured, how it works, and how it fits in the larger picture. This is one of the areas that AI is really not good at. If you see people developing AI, especially vibe coding, et cetera, you'll often see, almost exclusively see, people building new applications. Why? Because AI is a whole lot better at greenfield applications, meaning building something from scratch, compared to working within an existing code base. It's it doesn't have the ability to put enough of the context in its brain. And so often what you'll find is that it will change how your code is structured or how you do things, and and it won't follow your patterns that you have in the rest of your code. Or it won't use some of the methods and some of the classes that you have in your code and will recreate those. It'll violate dry all over the place. It will violate a lot of things to put different architectures in place that don't really fit within the larger picture. So understand how to review code and then with that have a better understanding of architecture so that you understand what's a good, well-written code base and what's not. And so you can say, hey, this code might work on its own and it might be fine in another situation, but in this situation, we need to make a change. And so learn how to do that. Number three, learn more about trade-offs in development. Too many developers have one solution for one problem. When you say, hey, I need to put data in a database, and they say SQL, you're like, okay, but I haven't told you my situation yet. Okay, tell me situation, but the answer is SQL. Well, but I have this SQL. See, that's not a good architectural standpoint. That's not that's not good as a developer when you're saying, I have this solution for this, you know, this set of problems. You need to make sure that you have more options. Understand the trade-offs. Understand when it might be the right choice for a NoSQL database. Understand what might be the right choice for a MySQL database as opposed to a Microsoft SQL database. Understand when it might be better to have Postgres, or it might be better to have CosmosDB or something else. Understand the trade-offs. That way you can make better decisions. Number four, get better at catching AI mistakes. If you think that AI doesn't make mistakes, then you're making mistakes. And if you think that the code that AI writes is great code, then you're making mistakes. Learn to catch the mistakes. Learn to better evaluate what code the AI writes. And then finally, prototype and build with AI. Yes, you should continue to use AI, but you should lead, not let it lead. So learn to be better at that. Learn to be better at being in charge. Use it to build and prototype things. We talked about the idea uh before about last week about uh progressive web apps versus a native app. And we talked about the idea that you have to sometimes prototype, make sure that these things can be done. Well, that's a great place where you can tell an AI, hey, I want to do this, try that. And maybe you just let it write, vibe code the whole thing. Because the goal is not to create production-level code. The goal is to see, can it be done? And then evaluate what it does and read the code, evaluate how it worked and say, you know what, this is this is bad. This shouldn't be done at all. There's some security holes here. Evaluate that, but use it to prototype, use it to build tools that you need. There are certain things that just don't need to be production ready, heavily used. They may just need to be a tool that runs on your PC or runs in your local network. Build that with AI. Learn how to get better at it. Learn how to let it do more work while still adequately reviewing it, still looking at the architecture, looking at how it builds things, looking at how it writes the code, making sure that it writes good code, making sure it's not mistakes, making sure you evaluate security and make sure that you don't have, you know, go beyond just, does it have API keys in there? Look beyond just that for security, but make sure that also is taken care of. So these are things you can do that will help protect your career. I just gave this advice to my nephew. It's four words that can change your life. Do the hard thing. Everyone else will be taking shortcuts, or it feels that way. But everyone else will be taking shortcuts and seemingly getting ahead. Do the hard thing and be left standing when they've lost their jobs. Okay? Do the hard thing. Put in the work. Don't just take a shortcut. Make sure that you're putting in the work, learning the how things work, not just how to push a button with an AI. Do the hard thing and get ahead in your career. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 19:22

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.