If you can find a better place, get out. It's one thing that the code is bad, it's another that they just don't care. Now you know what question to ask during the interview...
Ask HN: Started a new job and their existing code sucks. What to do?
21–30 of 66 posts
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#22Re: Ask HN: Started a new job and their existing code sucks. What to do?
#23Refactoring is almost never a priority at a real company that has brought a product to market. Either the culture there is receptive to it, or you're better off learning to live with it. Sometimes you can get away with small, incremental refactors of things that touch the new code you check in.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#24> they acknowledge that some refactoring is necessary, they don't think that's a priority (and that we should focus on bug fixing)
Sounds like they're more interested in make-work and job security than creating a good product. You may wanna get out of there.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#25Consider the fact that you just joined the company, and are likely unaware of many complexities, dependencies, and edge cases that the code must account for. I suggest working with the code a bit longer before you make such bold proclamations as to its quality. Also consider your teammates built that code. How do you think they felt when you told them it needs a whole refactoring? Since you cannot refactor it in secr…
> likely unaware of many complexities, dependencies, and edge cases that the code must account for
All of this argues in favor of having an overall architecture that can help a team member grasp these complexities. Maybe there is one that OP cannot see. However, edge cases also cry out for automated tests. Whether or not a codebase has automated tests is explicitly clear from the first day.
> So it's important to have their support in refactoring
This is absolutely true. A software team is made of people and trying to drive change without respecting people's need to be persuaded is both rude and doomed to failure. That persuasion is hard and I wish I had better advice for OP than to read books by the Harvard Negotiation Project.
> How do you think they felt when you told them it needs a whole refactoring?
Depends on the teammates. I've built a codebase that was a pile of spaghetti before and I felt terrible about it and left. So there may be people who agree with OP that the codebase needs significant improvement. There may be other people who, in the style of https://danluu.com/wat/, never imagined that things could be better.
But one thing that the current teammates have in common is that they all have not left. The people who care most about clean code are the people who self-selected out of the team already.
> It seems like a needless risk.
So is making any change to the codebase without tests.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#26About 2 years ago, I was in the same position as you. Had been freelancing for years, then went back to full-time employment. It was quite a change from what I was used to. IE: working with a very small team of people I chose and have worked with before.
A lot of the advice I've seen here relies on the rest of the team wanting things to get better. That's not always the case. Many teams are very proud of their unmaintanable, untestable spaghetti. Some see it as a of badge of honour that nobody else can figure out something as basic as where model validation happens (in that specific case, they marshalled all their model validation into the controller parent class, and things got worse from there).
So the first thing you need to do is figure out how open they are to changing. If they're happy with what they've got, and they don't want to change how they write code, then there's not much you can do. Cleaning as you go is a great idea. But even if there's only one other person on the team and and they don't want to change anything, they'll be generating mess twice as fast as you can clean (making a mess is always faster than cleaning).
That's my advice. Try to probe if they're willing to admit they even have a problem. Start with floating the idea of writing tests, or implementing a style guide. If they don't even want to do that, there's no way you're gonna get anything bigger out of them. At that point, you gotta decide if this job is right for you.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#27[deleted]
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#28Here's the idealistic answer: see if you can get a very private interview with the head of the company; even the board of directors. You are accepting money, so you actually have an obligation to get this information to them. Doesn't mean you'll be believed necessarily, and yes it's high risk but the obligation is there and the reward - the difference you'd be making if the ship can be turned around - is large.
Of course, the other side of the argument is that it's not unlikely the head of the company is the guy who created this problem, so maybe looking up one of the board of directors, or an investor, is a better idea.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#29Here's the idealistic answer: see if you can get a very private interview with the head of the company; even the board of directors. You are accepting money, so you actually have an obligation to get this information to them. Doesn't mean you'll be believed necessarily, and yes it's high risk but the obligation is there and the reward - the difference you'd be making if the ship can be turned around - is large. Of co…
oh no way do this until you've been there many months.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#30Here's the idealistic answer: see if you can get a very private interview with the head of the company; even the board of directors. You are accepting money, so you actually have an obligation to get this information to them. Doesn't mean you'll be believed necessarily, and yes it's high risk but the obligation is there and the reward - the difference you'd be making if the ship can be turned around - is large. Of co…
> very private interview with the head of the company; even the board of directors
Are you assuming that OP works in a small SV startup? Most jobs are in companies where that isn't plausible.