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

If you're much younger than this other developer both professionally and biologically, then just fall in line, to be frank. Do your best. Try to help them out. Always be learning. Eventually maybe they'll move on, or you'll find a better opportunity. But don't under any circumstances badmouth anyone, or try to undermine anyone, or get into an it's-me-or-them situation, these things will only set you back.

I think if you are in the position of asking your manager for permission to refactor or rewrite or whatever, the problem has been framed incorrectly. Managers are for helping people work together, and helping them understand what is important to the rest of the company, and helping the rest of the company understand what you are doing, and helping you understand how to succeed at the company, and... many other things along those lines. They're not for telling you what buttons you're allowed to push on your computer.

Your high level goal should not be to own the code, but rather the problem that the code solves. Then you are in charge of deciding whether to refactor the existing code, or make a fresh start, or something in between. But you have to make the right decision. As a professional, you take responsibility for doing the right thing given the context in which you operate -- the state of the business and the people working around you and of course the existing systems in place. As a professional, you are trustworthy and trusted. You write code when it is appropriate, solving the most important problem at hand in an efficient and maintainable fashion. You account for both short term and long term priorities when making decisions. You communicate thoroughly. You don't make big mistakes, and you own your small mistakes and fix them as soon as possible.

In your career decisions, you should think strategically and follow a path that leads where you want to go. Will this role help you become a mature professional? Do you have mentors to learn from? Will you have a balance of maintenance and greenfield development? Do you see people working there who have healthy levels of autonomy/mastery/purpose?

So overall, just keep your chin up and do your best.

But damn how do they not have tests.

But how do you objectively measure "improvement of the code"?

Maybe it's something fairly obvious like better performance, less bugs, etc, but a lot of times it's very hard to tell if there was actually an improvement or just a different way of doing the same thing, except at the added cost of re-implementing those 3 years of work.

And for the record, I agree with you in that you (we) should leave your ego at the door, and if some young whippersnapper can do better than you, then you should be able to leverage that and increase the productivity/performance of the team/company.

However I've seen it happen many times where someone thinks they will improve the code but in reality (like others have said) they don't have the correct context and forget about a lot of stuff that their "improvement" should take into account but doesn't... and then once they do the "aha!" moment kicks in and they realize why it wasn't as easy to improve as they first thought.

Don't refactor it right away. I'll take your word that the code is shit (frequently the case), but you don't know the idiosyncrasies well enough to know what to do with it.

After you've worked with the code a while, you'll be able to attempt a large refactor. Until then, gather low hanging fruit. Clean up confusing variable names. Add comments where needed. Write your new code as clearly and cleanly as possible. Use a tool like sonar to inspect your new code so that you don't introduce new problems.

Most importantly, ADD UNIT TESTS. That will make sure that your new code works with the old and it will allow you to attempt a larger refactor while being sure that you aren't breaking anything.

If necessary, you may need to add some integration tests as well.

I've been in your shoes. Bad code is no fun, but don't let it get you down. Focus on the happy parts of your job (team, culture, whatever). Good luck!

1) As tempting as it is, DO NOT refactor the code right now. Do the minimal amount of work needed to complete the task.

2) Start etching out some time with your manager/tech-lead to start writing unit tests for the code.

3) Gradually refactor code that is unit tested.