 Welcome on having coffee with smoke! Today we are talking about habits that will kill your programming career. So grab yourself something warm, nice to drink and let's begin! So today we are talking about things that could kill your career even before it began and also things that, well, basically could end it or get you the pink slip. So, you know, listen up and pay attention. Beginners, programmers that are only starting their career are often encouraged by their colleagues, their people who already are a little bit in the business, to start doing their own projects and like, keep learning, keep reading the books and so on, so forth. Hence the mug. So what happens is you set up your IDE, you start writing some code, you copy paste from Stack Overflow or from some tutorial and then you fiddle with it. You change one thing with the other and see what happens. Then you change another thing and see what happens. Well, that's a fun thing to do when you don't know what you're doing, but if you're actually aiming for a career in software development, well, get the done book and read it. Even if you come up with understanding what each keyword does, what are the control structures, variable, so on, so forth, you will actually never learn the programming and the first job interview that you're going to will be basically a mess because software recruiters are very well trained into discovering this kind of approach. You need to know your coding, you need to know your syntax, you need to know what you're doing. Well, if you're not serious about what you're doing, it's fine, but like in a proper project, you should never do that because, well, come on, who are we trying to trick right now? Either you know what you're doing or you don't. So stop brute forcing your code until success. Start actually learning the things and get them right. Avoid wood programming, never do it. Very good coffee. All right, on to the next one. So as I mentioned, wood programming, it kind of brings us to the second habit that I find, well, at least detrimental to health of your software developer career. It's being lazy and not the good kind of lazy because, of course, programmers are pretty lazy people and when they don't want to do something manually, they will write a program for it. So not this kind of lazy, being lazy as an insightful. As an insightful, that means you don't really actually care how things are created, how they are working. You accept some sort of approach without the full understanding why we should do that. Okay, let's say that you follow design patterns or you follow clean code recommendations from Robert Martin or somebody else. What you should do is actually learn the rules and follow them as long as it makes sense, right? So you need to have this notion on why the rules are, what do they mean, and when they do not apply. Okay, on to the habit number three, cargo cult programming. Look it up. So cargo food programming practically means that, well, you copy and paste. It's commonly known as stack overflow programming. So you have this problem that you're trying to solve and you go online, you find a solution and then you blindly copy and paste it into your code without actually checking what it does. So cargo code programming is this inclusion of code that we don't understand perhaps that is was written by somebody else or following, let's say, design pattern that we don't actually need in this particular case because we don't really understand what the design pattern is about. So we do that because we don't actually care about the solution, we just want to get it over with and that's it. So don't practice cargo code programming, avoid it as much as you can. It will lead you astray and you will actually never become a proper programmer. Thing number four, the old dog attitude. And what that means is, well, you don't actually learn new things on your own or you try to avoid learning new things. You'd rather resort to a scenario, a code or a practice that you already know and mastered, you rely on things that you learned back in the day and you don't try to incorporate new tools in your tool belt. That's a major mistake. So listen up. If you actually want to have a career, not just a job in software development, you need to constantly evolve. You're not in a funeral business. You don't do the same thing for hundreds of years. You come up with new ideas, new methods, easier, better, faster to solve the problem. If you're unable to pick up new things along the way and as you go into your career, somebody else will. And that practically means that you will be left out. So back in the day, I was working in this company that had C++ in it. And we were slowly transforming our code to use C++ 11. So we were updating the C++ code to use those curly braces instead of assignments when we were creating new variables, right, when we were declaring new variables. And this was done by junior developer. So on the other end, there was the senior guy that randomly decided to check this piece of code without understanding what the change is about. And it seems that he didn't have a lot of information about C++ 11 and how it was structured and what are new things in it. So the code that he was reviewing was basically littered with useless comments about removing all of the new things that we were introducing, because he thought that we are actually breaking the code and joking as we were making the changes. Yeah, and this story kind of became a legend in this company. So, you know, keep up to date with stuff. So thing number five is called big ball of mud. Big ball of mud basically means that in our solution, we are not following any clear architecture. We don't have a overall hierarchy that governs how we are structuring our code and where everybody and how is everything written. So I understand that sometimes we get dragged into such projects and we don't have a lot of power to change things, right? We just are in this project that is following no architecture or something like that. But if we can, we always should avoid this kind of approach. And if we end up being in such a project, we should actually allocate resources to change it. Because what that actually means is you will have faster burnout. And it's kind of the case that this happens when we have big rotation of people. And partly I think that rotation happens because of the bad architecture, right? Because there is a lot of chair around software that doesn't have a clear architecture. There is a lot of mistakes, a lot of errors, a lot of maintenance involved. So changing one piece of the code basically means that some wheels will break somewhere and you don't know where, why or how. And you cannot do anything about it. So to change it is of course a big cost. But the sooner you do it, the less money you will waste. So why not do it as soon as possible? So to be fair, it's not about somebody who I met, who I worked with. It's a situation that I just heard about, right? So drinking on the job. So a lot of companies want to be in this body-body relationships with their employees, with their developers. And they trust them enough that they put fridges in the office with beer or other alcohol in it. And I'm not advocating against this, right? It's totally fine. If you want to have the beer fridge in the office, great. Free beer is always great. Don't get me wrong. But I think that it should only happen when we are finishing the day and everything important is done. We just want to hang around and chill for a bit before we go home or I don't know how to party. So writing code when you're drunk is kind of like driving. You should never do it because you might kill somebody or yourself. And on top of that, in many countries it's actually illegal to drink in the office. So just be aware of that. All right, seven. So number seven is swearing in the code. So swearing in the code is especially visible with self-taught programmers. Self-taught programmers who, well, didn't have a lot of teamwork before. And I find it probably not as disturbing as something else, but I think it will, it may cost you your job, basically, and it almost cost me mine. And the story goes like this. I was developing this, let's say, integration piece between two platforms. And for some reason, I decided that when one platform is calling the other for a token and the token is invalid, the first platform should return something like something insulting to the user. It was being funny at the moment. And I eventually planned to remove this, right? So it should never see the light of the day. What happened is for whatever reason, I didn't save my changes or didn't create a correct commit or something like that. And the change went online. So, yeah, I've never done it before, or ever since. It was my lesson that was well remembered. So I was extremely lucky because what happened is during this integration, one of the developers on the other side that was on the receiving end of this integration was checking if everything is working, and I received this phone call. And the guy is saying, okay, I'm working for this company and we have your integration here and we are testing it. I think you have a mistake in your code. And he's like, what? How? Everything is tested. Like, how could this happen? And he says, yeah, could you change the label that appears when the token is invalid? It's like, it's a bit inappropriate. And I'm like, what? I don't even remember what was there. Like logging on the website, checking the thing. And it's like, oh, your token sucks dick. And I'm like, oh my God. Oh my God. Why did I do this? It's so easy to forget about this. Never ever do this. Like, avoid this because the guy who spotted this actually knew that these things happen. And he decided to reach out directly and save my ass practically. So thanks for that. If you happen to do this on a proper job, you might get actually fired for this. I think it's a fireball offense. So especially when it comes, you know, it's visible by the end customer of the company somewhere outside of the system. So be aware of that and never put swear words in the code. Always try to be as polite as possible. And also be mindful of your fellow developers, right? They may not be in the mood of reading swear words during their morning coffee, right? Habit number eight is being selfish or solo player. I think you shouldn't be selfish person, right? It's not a good thing. The more you share your knowledge, your time with people, the more you actually give value to other people, the more value you will get in return. I think it's a commonly known truth. Somebody may say it's karma, but what I actually think it's not a karma or anything like that is basically like courtesy, common human decency, right? If somebody will review your code, make sure that you review their code, make sure that you're helping them, make sure that you're being friendly and polite to other developers in your team. And don't try to be this ace or solo player that knows everything and doesn't need any help as well, because when somebody helps you, you're not only learning different approach, you're not only learning different perspective, but you also learn how to cooperate with people and you give them a chance to become the good guy, to shine and to show off their skills. And you should be appreciative of other people's work, because yeah, why wouldn't you? Help each other out, and you will be helped as well. It's extremely important to work in team. And I'm not saying it's you, right? I'm pretty sure you're not a selfish person. I'm just reminding everybody, just trying it out there. All right, number nine is something that I see quite commonly in IT world, which is not having personal projects outside of IT, outside of your job, outside of your work. And I'm referring to both IT projects that you may do as a hobby of IT projects that will grow and help your career. But also I'm talking about something else that is totally unrelated to IT, because you need to avoid burnout. You cannot fall into workaholism, right? And this happens to us, because well, programming and being IT person, a software developer, is a thing that is extremely gratifying. It's extremely interesting. And we may lose touch with reality a bit. We may forget about other things that are out there. And you should always have something that you're doing outside of work. If it's a personal IT project, it's fine, as long as it's not connected to what you're doing at work. If it's a hobby, I don't know, acting, singing, playing a guitar, or making a YouTube videos, even if they are IT related, right? It helps you to take your mind off the work and reset, restart and recharge your batteries, right? Do something else. Possibly, if you can, sports are extremely a good thing to do. Going to the gym, playing a little football, even something simple as badminton is good enough. I'm guilty of not doing this myself, but maybe I should. And number 10 is very detrimental to your career. And it's kind of sneaky, because it's not that obvious to spot staying locked in your role, in your project, in your position. I think this is a thing that you should avoid if you can. I know people that are working on the same position, same team, same spot for years and years. And because of that, they are not advancing, right? They are set in their ways, they are happy in their little spot, and that's basically it. You don't advance anywhere. And when your career isn't advancing and years and years, nothing changed, yeah, it's already dead. So you need to use some thunderbolt, some rapid fire to revive the career. I mean, it's fine if you're close to retirement and like, okay, a year or two or even five, it's like, okay, you don't need to push to go on another level. You don't need to strive to get better or in the bigger projects or maybe something else like that. But if you're still a junior or regular developer, you should always think about how can you progress? Even if that doesn't mean transitioning to more senior position, maybe you could pick up a new role, maybe you can become a teacher, maybe you can become a person that is helping with promotion of your company, maybe somebody who goes outside and becomes an ambassador, an evangelist or somebody like that. Maybe I don't know, maybe you can become a mentor to a new joiner or maybe you could interview candidates that are coming into your company, right? All of these things are developing you as a person and they are helping growth of your career. You will become more valuable. You will become a person that is basically, you know, everybody will kill for you if they could have you in their company. If you don't know how to evolve the portfolio on your CD, on your resume, in most companies, you are free to start stuff that nobody asked you to do. You just come up to your manager and say, oh, could I become responsible for this project that is, I don't know, in its legacy stage and nobody's actually taking care of it? That's what I did in Ericsson. And everybody suddenly said, ooh, somebody has some initiative. Well, maybe it's worth to put you into some other tasks. Maybe you don't need to work on this legacy project that we don't care much about right now. Maybe we should give you something more. Maybe we will, you know, grow your career in different directions, help you get to next level because you're the guy that actually wants to do stuff. That means that you are worth to being invested in. We will grow, you will develop, you will help you to get to the next level. You will give you more responsibility and more money. So, yeah. And now the bonus. The worst habit that will kill your career is not subscribing to this channel. So go ahead and do it right now if you haven't subscribed yet and I'll see you in the next one. Thanks so much and cheers.