Would you leave a company for terrible code?
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 ] threadOften 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?
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.
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 lasted two weeks in a place where the CTO built the stack for most of the company's life and had trouble letting go.
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.
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.