As long as their salary keeps increasing, I'd say go for it!
You only hurt yourself down the line. My last job had not improved their own product, processes, tools or frameworks, so everything was still stuck in the 90s. Their product was build on an discontinued an proprietary database and server system you never heard about, jQuery UI from 10 years ago and other BS.
However if you don't upskill yourself in this situation you will be unemployable in the future, because all other employers demand modern technologies, git, docker, unit testing etc., which I was yelled at in meetings for suggesting it.
My first thought!
Project A: Has 6 different implementations of the same complex business logic.
Project B: Has one implementation of the complex business logic... But it's ALL in one function with 17 arguments and 1288 lines of code.
"The toast always lands the buttered side down."
Permanently Deleted
After so many years in this company, lots of the unmaintainable code I have to deal with is either my own fault, or the fault of someone I used to work with but and now they left and I'm the one who has to apologize for their code.
If I move to a different company, 100% of the unmaintainable code I'll have to deal with there will be someone else's fault.
In the industry we call this responsibility load balancing
And managers don't like it when you explain that the code is a unmanageable mess because they put a deadline on every goddamn thing and never pay off technical debt.
At a new place you can honestly say "the code is kinda a mess, it needs a bunch of work" and the manager can just assume it was because the last guy didn't know what he was doing and not because of their own shitty management.
Sometimes a fresh pair of eyes on a code base can reveal some opportunities for big improvements in maintainability 😜
Ahahhahhahha. Ha.....ha. Ahem.
Sorry. The idea that any of the opportunities for improvement at my last "job A" code base might need "revealed" struck me as really funny.
Sometimes there's an opportunity to delete it and start again 😜
Sometimes it takes a new dev coming in for management to give the greenlight for a major overhaul. It’s shitty, but it’s true.
Also new people are still motivated to change stuff. They are not yet worn down by bureaucracy.
Opportunity is my managers favorite word. I even got him an ink stamp that said “certified opportunity”
Looks like we found the hr employee! Get 'im Bois!
Lol, nah I'm a developer.
In that Xamarin mess? The last handover only made things worse.
Recently switched jobs from maintaining a 15 year old Windows Forms .NET Framework legacy codebase.
At the new job we stick to Clean Architecture, use unit and integration tests, have a code generation tool, actually make nice use of generics and use dependency injection. Also agile processes, automatic build tools, whatever. The difference is night and day and I'm so glad my ex boss fired me because I told him he's an asshole and his codebase is shit.
My first job out of college I have been able to see a steady improvement in the codebase. A little while ago I had to go back to an old tag and was horrified with what it used to be and impressed how much it improved.
You have to listen to your heart, at least once in your career, to learn that grass on the other side is covered in just as much dog shit as it is over here.
"Maybe the grass is greener on the other side because you're not over there fucking it up."
-Abraham Lincoln
I’ve known people who do this several times in a year. One even came back to his old job, just to leave it within months to go to a new one, brag about how much better it is. He moved on from that job too within a year.
Might just be the entire industry has reached enshittification in more than one way.
To me, a corporation cannot maintain quality code because requirements are ill defined, and there is no “done” state. With those two conditions present, unable to be changed, it’s not possible to form a coherent codebase. Those who try will make things worse, because their abstractions won’t fit in a year or two.
This is exactly the “messy code” people then leave behind. Bad code can come about for other reasons too, of course, but this is one of the more annoying reasons, because someone wrote it with self-righteousness, as if they were the only people to truly SEE the problem. Sigh.
It’s fine, this is how enterprise works. You can learn to navigate and make a living from it. You MUST internalize and accept that it is NOT the same as maintaining code for an open source library or whatever people think it’s going to be.
Just rewrite it with 80% functionality and force migrations on the users. Once the remaining 20% "edge cases" that require serious effort hop to the next job - where you where hired to "maintain" such a system and "just add a small feature here and there". Ooops.
Reddit: You're hired!
Project A: Has 6 different implementations of the same complex business logic.
Project B: Has one implementation of the complex business logic... But it's ALL in one function with 17 arguments and 1288 lines of code.
"The toast always lands the buttered side down."
Learning to deal with "unmaintanable" codebases is a pretty good skill. It taught me good documentation and refactoring manners. It's only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.
Code should scream it's intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don't). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today's version). Tests are documentation. Often the only up to date one?
This right here. Get good at navigating code of questionable quality that you didn’t write. If you can’t do it, start questioning your tools, and mastery of those tools. For the big boy jobs, you should be working with existing code much more than writing new code. Learn to get excited by tweaking existing systems with a few well placed, well researched changes, instead of being The Asshole that adds a new abstraction wart.
I’ve known influential assholes who poopood commentating as if it’s only a superficial job.
I hate those people.
Switching jobs can be worth it just for the change up.
Can we arrange some swaps? I'm not getting paid enough and neither are you.
Some intern writing spaghetti which a company is going to be based off
Meanwhile, Dev of company C driving off a bridge, getting laid off after modernizing the 90s era codebase.
I left a company when management decided to discontinue a product right after we finally made its code more maintainable.
Had a look at the product that would replace it, and it was a bigger mess from what we started with.
I see it as a win, I love refactoring bad code . Just feels so nice afterwards.
Especially when you can remove thousands of lines of duplicated ui code.
That's so much better than writing new code
You guys are getting codebases?
Creative_assembly.webp
