Ask HN: Codebase at my work is a complete mess, what should I do?

I work in a similar company in the past, and having tests / a build server is step 1 to empower other to refactor more. The lack of tests is usually what brings people to paralysis / creep / huge tech debt ime.

And don't forget that beautiful code is not actually necessary for business. What is needed is delivering value to your users in a consistent manner. Well structured code will be needed if the project is here to last in the long run, but it is not always the case.

As far as I can read, you're doing great. Keep it going and other are likely to look up on you in the future, and you'll grow a lot.

Frame it correctly: "I don't understand why these classes share this data or code, do you remember why?" is miles better than "Explain me this mess please it's making me crazy"

If the original dev is still around focus on the task that come from business so he's free to focus on fixing the structure, he is, after all, the local expert on it.

In general a rewrite is not something you'd do without having a clear understanding of the requirements. What you can do instead if you don't have the dev support is to fix thing as you go, removing cross dependencies and encapsulating behaviors. You don't have to fix code only to hide the ugliness behind a clear structure and as small as possible interfaces, order will eventually emerge.

My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Your job at first is simply to understand the code and demonstrate that you are able make improvements to it without breaking everything. Doing so will win you the trust and respect of your teammates, whereas if you come right out of the gate trying to rewrite everything there is a very good chance you will make yourself look like an ass by spending a lot of time and energy introducing bugs into a previously-stable area of the code. Once you have a decent understanding of how and why the code is the way it is, and the trust of your teammates, then you can invest effort into fixing the highest-priority issues with the code.

Being able to read and work effectively in legacy code is an essential skill for any software engineer. For now you should just try to focus on fixing bugs and implementing new features, and take pleasure in the fact that you are improving the project and developing a handful of hard and soft professional skills.

That being said - there should be a limit to how much bullshit you put up with. If after six months to a year you still find that you hate the job, and a better opportunity comes along, then go ahead and take it.

Here's what actually happens.

By that point in a project's lifecycle, that's not what they usually ask of the new hires. People are usually tasked with fixing bugs/maintenance, and implementing new business logic. Both of which are extremely challenging and stressful when working on a project that comes with no tests, or documentation.

Your actual task as the new hire is to start generating more value for the company, but that's so much more challenging when you have no way of validating your solutions, no infrastructure to rely on, and no metrics or documentation to consult. At that point, being the new hire, you're taking a lot of heat for not getting things done on time - mostly through no fault of your own. At that point, "wanting to throw you under the bus to your superiors" is a very natural response - it's a defense mechanism, you're (rightfully) frustrated. You're between a rock and a hard place. At that point you're no longer doing software engineering, it turns to politics/coverups/fire-extinguishing on a daily basis. Can you not relate to that?