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

Edit: definitely kick the tires a bit by seeing if this situation is typical for the company, or if it's an outlier.

Regardless of the exact situation, there should always be a way for you to work on your craft. It sounds like you are doing a lot of refactoring now and that could be quite rewarding, even without tests. If you find yourself trying hard to improve the environment and feel like it is to no avail and that no one is listening, while simultaneously feeling like you can’t leave the job in the short term, you might want to think about how to take advantage of the dead time at work to learn new things or do other activities that improve your skills.

1. Try to get the political will to change it, then lead a change. This is essentially impossible unless you're a respected senior developer, and even there it is hard. There is a lot of advice out there, but the primary thing I've seen work is this: Complete feature freeze. API-ify the backend with heavy tests through the API. Have the presentation layer slowly shift to the new API. Once the API is complete, delete all the other backend code. Refactor the presentation layer with tests as you go.

2. Accept that the codebase is shit and look at your situation realistically. If you can't switch jobs (visa issues, etc) you need to accept that this is the way it is at this company and don't grumble about it. Spend 20% of your time making tools that help you compensate for the shit quality of the codebase; admittedly this is easier on non-Windows projects. Even so, making a small tools for disorganized projects really helps make you look super pro, even if the code is doing most of the work.

3. Quit and work somewhere else with better people and a better codebase.

Out of all the reasons I advocate TDD, from cybersecurity to QA, they pale in comparison to employee retention. Keeping a codebase clean over time requires tests. It just does. If you don't have tests things ossify. I don't write tests for ad-hoc querying data, but I always write them for long lived projects and I refuse to work on established projects that don't have test suites (or direction from on-high to add them).

No, absolutely not.

Look for the positives in what has already been accomplished, then sell them on the idea that "it can be even better."

Since it sounds like they are fine with you making improvements, just take it one step at a time and keep at it.

The code base that exists took many hours to develop. You wouldn't have a job at all if it didn't exist in some kind of functional state, no matter how bad it is.

Don't brag. Don't position yourself as some know-it-all hot shot. Just keep improving things and let your work speak for itself.

Ideally, you want to get good at explaining why the change matters in terms that make sense to the non technical folks involved in making decisions.

Do make sure they know you did the work. Don't let someone else get credit for it.