I've struggled with this a lot. If you want to talk over the phone or via discord I would be more than willing to be a sounding board. :) > Recently I joined a

I've struggled with this a lot. If you want to talk over the phone or via discord I would be more than willing to be a sounding board. :) > Recently I joined a relatively small company (50-100 employees) as a medium level software developer. For a while I was very excited about this opportunity. After few days/weeks of getting to know the whole codebase I finally moved to a specific project I was suppose to work on and I found out the code is a complete mess. Yep > Often I find parts of code that unintentionally affects other parts of code. Some parts are just copied and left there doing nothing. Even names of classes/variables are sometimes useless and project structure is unintuitive and seemingly without rules. It's spaghetti and relatively big spaghetti (tens of thousands of LOC). CACE principal at work. > I started "repairing" the project but there're no tests to check whether my adjustments are correct.

 Start writing tests, start motivating other contributors to write tests. Focus on the code that matters. > I'm so frustrated and depressed by it. The job basically turned into something I hate - I'm just rewriting the code! You're going to need to work through this and either change your mindset about this or start looking for a new job. I challenge you to do the former and not the latter. This is how 90% of the projects you're going to jump into are going to be. The real test will be whether or not you can thread the needle and make valuable improvements to the code while also delivering business needs. You can't let this job get you down. I know... it's your vocation, but most of the time people treat their job like a sweet paycheck. Instead you're going to need to treat this as a challenge if you want to get through it. You've identified the problems, now you can either continue to be negative and wallow (bitch) or, attempt to offer solutions to fix them. The challenge is not so much technical as it is cultural. You'll need to be able to communicate the value of the changes that you want to make. You'll need to change the mindset of the stakeholders of the people on the project to let them know why integration tests are not unit tests. Why, separation of concerns is important and how you plan on doing that. Otherwise, you won't be able to create change and this is the cultural challenge. The bad news is that this isn't necessarily the exact job you signed up for as an engineer. The good news is that you'll be able to build new valuable skills that are often highly sought after. If you feel like you're a "better engineer" than the current engineer that built it, then you need to help elevate that engineer and the other engineers around them. Otherwise if you become depressive or negative on the job, you're going to have a major negative impact on the rest of the team. > The person in charge of this project was working on it alone and from the outside it all looks fine and it's working. So this makes the higher people think that it's all just fine. Welcome to business life. This is how it's going to be a lot. I'm sorry. > I really don't know what to do. Should I just go and basically say that this person did a bad job? I don't feel very comfortably doing that because (a) I'm a relatively new hire, (b) the person in charge is working there for about two years and (c) I'm much younger than she/he is both professionally and biologically. No, don't go in and blame the person who wrote it. You always need to "consider the context". It's easy to point at someone's code and call it shit, or to say that a project needs to be rewritten. It's harder to reverse engineer the "why" of how it got to where it is. If you can identify the "why" then you'll have more insight as to how you may be able to fix the problem or address the aspects that may have caused the problem. > I've already made some comments about rewriting it and the response was basically "ok". "ok" or in other words, "how are you going to deliver business value for our team". Show them data, show them why having easy to maintain code delivers business value, then people's ears will prick up. It's your job to manage this problem. If you have the necessary insights, it's on you to fix that. Otherwise move on and don't let it kill you. I know, my job is very important to me as well, you can't make yourself miserable over something like this. It will be far too prevalent in this field.