Would you leave a company for terrible code?

6 points by OhNoNotAgain_99 ↗ HN
The people are nice, but your held against a dude that aged with the company, the code is horrible despite everyone thinks he's a guru. Its aged poorly documented and there is no will to upgrade it. I'm in a moral dilemma.

12 comments

[ 82.9 ms ] story [ 697 ms ] thread
Or maybe it is the best opportunity ever to really make a difference, depends how you frame it.
if they indeed went for what i got a job opening to upgrade their code, but i was never put to work of refactoring re-writing, while their code depth is huge. Getting blamed of coding slow with 'their' code (an obvious result of their mesh). I feel kinda lurked into a death trap, the code gives me real headaches. I put in extra pauze moments just trying to deal with it, but its a nightmare. Dont think i would like to live on like this for another year.
What do you do then?

Often companies respond very poorly to predicted failure (or success) and need to see these scenarios demonstrated.

Rather than wait for failure, or just disappear, can you take a piece of code, refactor it, have tests for it, explain what you did and why, along with how a company coding standard could allow painless transformation incrementally across the entire codebase improving maintainability for the future?

what is the dilemma? Seems to me that if you can't abide working on the codebase, you have to do the right thing for you and the company and look for another employer.
This sounds like you're relatively new to the company - if so you might want to take a little time to really get to know the codebase and understand the business better.

I can certainly believe that there is no will to try to upgrade the code if it's horrible and poorly documented. The question I have is, would they be more willing to update it if they felt safer doing so? If you think they would then you could offer to put some tests in place to help you get a better understanding of the codebase. Once there's some tests in place that people can use to make sure their changes haven't broken anything then they might feel more comfortable to make changes.

Sadly one person's terrible code is another person's elegant design. The best way to figure out if your perception matches reality is to work for many companies, and see how teams balance different factors. I'm going to assume that your opinion is correct snd this guru is actually making bad code. In that case, this company is dysfunctional. Everyone is afraid to stand up to the guru. I have left similar companies, and was happy that in doing so I helped enforce survival of the fittest, we can't have companies like that prospering and cloning themselves.
I was sort of in the same position as you about 18 years ago. But all the guys who wrote that code moved on, the managers moved on. I hanged on, kept refactoring and fixing bugs in the horrible code, often alone. Also supporting internal users. I got to the point where I was the only one who knew it all, so managers didn't argue me and essentially let me do what I wanted. I became the team's technical lead, while the team itself disbanded and reformed 3 times around me. The code is much better now, although there are many dark corners left.

It takes some grit, determination, some belief in yourself and your abilities, and some minimal level of laissez-faire attitude in your level of the organization to get going. In the beginning I had encountered opposition to my changes, but in retrospect it wasn't that strong and I was allowed to have a small impact even then.

If that's not the situation in your case then I think you'd best move on, it's not worth it. If you do want to stay, I'd try to befriend that older guy or at least work with him and have him recognize that you're good and you mean well for his code, so he'll not object to your changes.

BTW, at the end I sort of became that old man myself... But I strive to be a much better one than the ones who were there when I came aboard. Me and my team lead, who "grew" together with me in the company and shares the same views, encourage refactorings, unit tests, and proper documentation, clean code and code reviews. She deals heroically with the pressures from management and users to add features quickly so I wouldn't have to.

I accept criticisms of my code and the app in general, and always try to explain to critics that I think they're absolutely right but there was a serious cost/benefit anaylsis done behind each bug or duplication that was knowingly left in the code from the old days. They are being dealt with, just very slowly and carefully. Like you, I still get a headache looking at the old pieces of the code which remain from that era, but they have been mostly phased out by now and next year I hope will be deleted completely.

I've done this.

I lasted two weeks in a place where the CTO built the stack for most of the company's life and had trouble letting go.

The question that I always keep in my mind: "Will I be a better developer after working on this?"

If you get a chance to to rework that horrible code and make something better of it, then maybe.

If you get incorporated until you too start outputting horrible things, then maybe time to move.

The code matters less than the culture fit here. Nobody on HN can know if the code is really horrible or if the guy is really a guru, but it clearly sounds like you are way out of sync with your workplace.

If you have mobility and feel very confident in your assessment, you should probably just leave.

You’re not going to convert everyone to see it your way any time soon and so you’re just going to be miserable if you stay and don’t buy in.

I fail to see the moral aspect of your "moral dilemma". Do you have some commitments or obligations that you didn't mention? If yes, that would be rather relevant for your question. If not - why do you think it would be somehow immoral (that's the implication, isn't it) to leave and move on? Not trolling - I genuinely don't understand your question, or not fully at least.