how to RUIN your developer career in 10 steps (without even knowing it)

I bet like most people out there are probably thinking how can I make the most out of 2025 and beyond? So number one mistake is hoping that your my cat will get better. Hoping it's not a good strategy in any kind of endeavor. And I'm here to tell you the market will probably not get better. You have to get better, you can get better. You cannot change the market, you can change yourself. So, if you are a software engineer and you really want to make the most out of 2025 and beyond, I beg you, sit down. You know, take out like two, three hours from your week. And write down what exactly would you like to achieve in your developer career in the next 12 months? And then think about what would be a plan to make that happen. Most people don't do this, most people don't have goals and then they wake up one day in a place they don't want to be and they ask themselves, how did that happen? Well, it's very simple, if you don't have a plan, you'll become part of someone else plan and you will end up in a place you don't probably want to be. Now, onto mistake number two, getting distracted by AI. Just if you're on a couple of searches, even here on YouTube, you'll find out that 2025 will be all about AI. Everybody's looking into what are the next AI tools or what are the models, what will open AI do, blah blah blah. The reality is, yes, AI is part of our workflow today. I hope it's definitely part of your workflow, but what we are seeing and we've seen for the last couple of months is that there's a diminishing results in integrating AI in the companies and also that the tools that you see today didn't change much. Like if we look at in even in 2024, the difference between GPTOT and GPTO4 was not big. And so a lot of people are trying to upskill themselves into AI or become machine learning engineers. Uh they start with this Udemy courses, or then they they, you know, get into, okay, how to how to they use AI, they get this formal. Uh, but in reality, you still need to get better as a developer. Of course you can leverage AI, you can use AI, but you are still the the engineer, you're still the accountant, you're still the thinking unit in the process of building software. So don't get distracted.

tivated by AI. Moving on to number three, not using AI at all. This is the opposite of number two. So we see software engineers even today being reluctant to use things like Copilot or even Coso, which is basically a VS Code with native AI. If you're not using AI in 2025, you will be basically left out. You need to integrate AI tools in your workflow and it will make you a better developer because you realize that these tools are really good at auto completing or writing code that's already kind of structured. They so much they missed out, right? But you do need to be using AI. If you're not using AI, if you're not using Copilot, if you're not using any of the AI powered coders that are coming out. You will be left out and I can bet in 2025 you will see those things in the job descriptions. Number four, it's still thinking in frameworks and libraries. I talk to we developers on calls, I talk to them on the phone and they always ask me like, oh do you think Redux matters in 2025? Do you think React matters? And I think that happens because of mostly two reasons. Number one, in the software community as a whole, we have a bit of an obsession with the next big thing, the new thing, the new framework, the new library. That's how the creators of the libraries and the people behind it try to to sell them, to get adoption. And the second part, it's a lot of software developers, like they learn first with a framework with React or Angular or View or maybe in the back end with Node.js and they thought we've been introduced to software engineering via frameworks and libraries. Now, this kind of thinking, it's obsolete for many different reasons. And I think, you have a very nice uh example because you work a lot with these frameworks and libraries, why are developers, you know, why is it a mistake to still be thinking frameworks and libraries? So, a very recent example I run into is the new release of of Next JS, which included a lot of things, um but everybody was talking about the updates in the caching side of things. And they go in and they go, oh my god, you need to use this right now in in your application and it's either four new ways of caching. But nobody really talks about the fact that all of them were based on the principles that.

built any other caching system. Like when you look at HTTP caching, when you look at caching at database level, they're all bit following the same caching patterns. It's very unlikely that someone will reinvents in the next even 10 years. But what they do is, they kind of rebrand it and they add all this fomo, and as you mentioned, they try to sell you their next video or course or whatever, and it'll make you believe, you know, that in 2025, these are, you know, the next 15 features of React Angular or whatever, might end up putting all this time kind of chasing that, trying to learn their specific implementation to realize that in reality, it's just the implementation of a pattern that was already there. And so it's really important that you you manage that fomo, and when you start in the new year, when you look at the things you want to learn, sure, do take a look at the new releases, but always focus back on, okay, what are your core skills and make that bigger. On to number five, ignoring the fundamentals. And so, as I mentioned, because we get on to this treadmill of frameworks and and libraries and spend so much time on brain energy there, it's extremely hard to see the signal from the noise. When you look at software industry as as a whole and everything that's been happening in the last 25 years and the biggest padding change, right, starting with components framework like React, graphQL, at HTTP level, everything that happened in the cloud, a lot of them were already based on mental models that exist. So, all this revolution can be summarized to four to five mental models that you can use to really break down these things without you necessarily going into the detailed implementation. And a lot of developers will jump in and say, okay, well, you know, we have tailwind, but like what's the next nice UI library in in 2025 and is it chatCN or is it whatever, you know, versal tries to pull out and and push into their server side rendering, which is next, or in the back end kind of the same is happening. So, ignoring the fundamentals at a technical level will fuel all that imposter syndrome and it will fuel this anxiety that the more you learn, the more there is to learn, right? So, in that way that's a bit addictive because, you know, you go in and you um you kind of see all these new things and it feels like if you're

learn them, you feel safer, but in reality it will basically lead to you either burning out or developing very superficial knowledge. When a bug actually happens, you won't have the tools to actually really solve those because we always work at a surface of, you know, the libraries and the framework APIs that we know. Mistake number six, it's still thinking it's all about the code. And this is classic junior mid-level thinking, where because you're working all the time with the code, code, code, you as a software engineer think it's all about the code.

Meaning you don't care that much about testing, you don't care too much about debugging, you don't care too much about deployment and we'll talk about this in the following points. And the problem is that is that code it's only part of the picture. Yes, we need clean code, yes, you need to have an idea on how to deliver code that other people can read, deliver code that doesn't generate bugs. Now, at the fundamental level, companies don't care about your code, they care about the value added and the value added happens when that code is transformed into features and is put into the context of the bigger picture of the software you're working on.

You will double your value if you learn CCD, if you learn how to deploy those things to the cloud, and if you learn system design. And that will give you this holistic approach to to engineering because again, when we say it's all about the code, a lot of people might misunderstand themselves, oh, I need to go into cment manager or I need to learn design. That's not the thing. You want to get better technically. You still want to get better technically, but there's so many more technical issues and aspects of getting software ready to production than just coding.

And that's where you want to focus and that will augment and exponentially what you can already do at code level. Awesome, on to mistake number seven, forgetting that the only stack it's full stack. Yes, so this one goes in line with number six. You really want to see yourself as someone that can add value to a software product. You are a software developer, but some people miss the fact that we are software product developers.

So you're building a software product and what companies pay a lot of money for and the people they look for is the people that they can hire and from day one, they can talk to the product managers, look at the backlog and start adding value into the product. I say start adding value into the product. I then say writing tickets, because writing tickets might not be adding value into the product. But for you to be at that level of the full stack tinker, you need to go all the way from especially in web development from CSS, right? We talking about styles and layout to databases in structuring data.

And you want to be covering all the rainbow here. Now, depending on where you are, you might have different depth here. A lot of people might start on the client side. And it's not about like doing back end tomorrow, but really slowly moving towards you being able to add value and to build things vertically from the front end all the way to the database. And that's when you can own a feature, that's when you can look at the business, talk to product people and start adding value to it.

That's what companies are looking for. If you want to see exactly where you are on all these areas, take the technical assessment we we linked in the description and we'll let you know exactly where you are on all those master dimensions. But keep in mind that it's always about the full step. Yeah, and I would like to add on that, the expectations that the job market has over any kind of developer, back end developer, front end developer, has those those expectations have changed dramatically in the last years.

And as you can see it yourself, and as people talking to me, all the time they're telling me, you know, I was interviewing for a front end position and then they ask me about deployment and they ask me about my AWS setup and I had no clue because this is something handled by the DevOps, right? And again, going back to point number one, the job market won't change. Software companies are demanding a bit more from software engineers, no matter their specialization.

Then they were demanding a few years ago. This doesn't mean you need to become an expert in Kubernetes or Docker or any of those things, but it does mean you need to know what happens there and you need to know how to get them done at least, at least at a basic level. Regardless of whether you're a front end dev, a mobile dev, or a back end dev, you need to know a bit about deployment, a bit about software life cycle, a bit about How do you get your software to production? Cool. Now, on to point number eight, mistake number eight, doing anything else than getting better at your craft. Well, I can give you so many examples here. I have other friends that are building around SAS product with a business partner, they found, which is usually some Google Chrome extension that they build where you can parse something with GPT and they put behind a paywall, uh integrated it with a stripe API and rating, wow, I'm a business person now, I'm an entrepreneur, which is great. I mean, I I admire their ambition. But let's be honest, um if if you're the the SAS you build uh can be built in less than a week and it does already something that people can find super free, you're far away from that. And I can give you dozens of those examples and what usually happens or I've seen this movie a lot is they start super excited. And then, uh you know, once the tool it's out, the the excitement goes over, the burnout, like they they've been coding, they've been building that for six months. Uh they usually lose ground at their work because they're obviously working with uh working on these tools in their work time. They're exhausted and it ends up being just another project that somebody will forget about in in one or two years. And the other problem is they think like a lot of uh talking with them, a lot of people tell me, well, uh yeah, but I learn this and this because I did it in this uh you know, in this tool that I was building, but the reality is that's not a very intentional way to to develop your skills. They've been basically doing what they were already doing at work, uh but they basically worked for free. That's that's what they're basically doing. So, message for the developer watching us, don't get distracted, focus, it's your superpower, your attention, your time are very limited and if you want to make the most after 2025, focus on what you're already doing, focus on getting better at your craft. Forget about the quick win. On to mistake number nine, burning out. This is a big one because we see people asking us, how's the job market doing? What else should I learn in order for me to stay competitive? What can I do to have a future? Because, you know, AI it's around the corner and they put so much pressure on themselves. Like they start coding on the weekends, on the evenings, they uh start putting extra hours.

okay, but maybe the company is going to announce layoffs and I don't want to be on the list. Maybe they have too many commitments on the other parts of their life. And I see a lot of people burning out and burning out is very dangerous because it affects your mental health, it can kill your whole like, what's the point in being a great developer if you're not healthy? None of them, you just ruined your life.

So, what I would say developers in 2025, it's aim for balance. Despite all the noise that's going out there. Okay, despite all that stuff, do not kill yourself in front of your computer, be more worried about doing the right things than putting a hundred hours on the wrong staff, and take it easy, you only have one body. You got to take care of yourself if you want to be in the game for 20 years, and you have to make sure that you can show up the next day, right?

One reason that and I are here, after 11 years, still talking about JavaScript, still talking about CSS, is because whatever happened, we made sure we can show up the next day and just give it another shot. So don't burn out, which leads us to number 10, which is quitting altogether. I think this is a self-explanatory because winners never quit and quitters never win. Cliഷേ, but the real threat to developers in 2025.

It's not AI, it's not technology changing, it's not framework, you know, software not being written and used by the world. The biggest risk is you buying into this idea that software development is not worth it anymore as a career. You listening to people that are too negative about the market, so watch your company and you quitting based on, you know, based on one opinion or based on some temporal circumstances that will change.

So whatever you do in 2025, don't quit, keep hitting the ball. Again, folks, and I are very positive and very excited. About 2025, we have a lot of things going on. I think this is going to be year number 11 to 12. That we've been writing code, I'm really happy and I never regret the fact that I chose to become a developer. It opened the roads for almost infinite possibilities. to 2025. What's 2025 holding out, you know, how the market looks like, what can I do? Uh I only want to leave you with one phase.

Tomorrow will be better because you are going to be better. Unless you make it worse. So make sure you avoid these 10 mistakes, make sure you follow us, and make sure you check the other videos that we have on this channel which have only one goal, to help you become the best software engineer you can possibly come. We are very happy to be with you in 2025 and beyond.