Ask HN: Started a new job and their existing code sucks. What to do?

"Be a little more relaxed about this" is probably the best advice haha. I think I just freaked out when I saw their code/had to debug it. But, as @pascalxus said, this is probably very common in many places.

This is the fourth company I work for (not counting some freelancing).

Maybe you've been lucky so far working with good code.

Most code is like this, it's semi-painful to work in. Once you have been working on it a while you'll be more used to it.

I would spin it more like this. Hey if we refactor/rewrite this we can improve it and knock out these bugs in the process.

It may be hard to convince the company to spend money on refactoring let alone writing tests. But you can always ask in a positive way to start on parts of it.

You get paid the same, be positive, fix bugs/issues, improve things where you can. Keep making positive suggestions.

As a developer you're almost always going to feel the urge to rewrite every app from scratch. I expect the code is making them money and they just want to keep things moving for now.

At some point there is usually a rewrite from scratch, maybe that can be your project.

Good luck with your new gig.

There is no one magic bullet to deal with such a problem. Instead there are several things you can do in parallel to help. Whichever of these works for you depends on the industry and age of the company you are in.

If the company is fairly new, then bad code is kind of expected. There is a rush to get a product out the door, so shortcuts are taken. Given time for things to settle v2 will be better.

If its an established company or the code is legacy you can fix little bits as you go along. If documentation is lacking, write some - maybe even set up a wiki and bug tracking system if need be. If comments are lacking add some.

If you can demonstrate the bad code is costing the company more in man hours (and therefore money), then maybe propose a a series of refactoring projects in order to help improve the code and increase efficiency. I worked at a company that would have refactoring parties once a month with pizza and chipper. On the last Friday afternoon of the month we would review 10 random code files changed in the last month and tidy messy code, add comments, docs, unit test etc.

Suggest the company adopt some coding standards if they already haven't. Ditto code reviews and unit testing.

Of course not all companies are receptive to such changes. Some take the view that if the product works, why wasted time on frivolous extra like docs and code reviews. Sometimes when the code has been primarily the work of one person they might not take kindly to criticism - even if valid. In those cases all you can do is just do is to write your own code as best you can and not worry about what goes on around you. Bad code is a lot more common than you expect and life is easier when you accept that.

If there’s literally no structure in place for running tests, then OP cannot just add “a simple test case.” OP also needs to build the test runner. That requires convincing his manager, who is likely the one responsible for this mess (by claiming maintainable code is not a priority).

Personally I think it’s irresponsible to hire new employees before having a maintainable project. It’s much easier to onboard employees and delegate to them when they have a safe dev environment and testable projects to break while they learn.