You must log in or # to comment.
the next dev, Hey this obscure feature probably doesn’t work, should I fix it… No, I’ll just patch “temporary-fix-don’t-use” and let the next guy fix it properly.
I hate this kind of practice. It shows no empathy for the guy that will have to fix it.
Sounds like the corporation should have paid the first guys more
He is making the job worse for his team not his corporation. That’s not the way to deal with that.
The sense of obligation towards your coworkers is something companies absolutely abuse and exploit. I’m not saying don’t have empathy for your fellow human, but people aren’t typically incentivized to use best possible solutions if they take more work outside of this obligation so you have to be careful to not let yourself be exploited because of it.
It’s not just pay. Things like pensions that would encourage long tenures have been all but eliminated from compensation packages. The idea of staying at a job for more than 3 years, especially in IT, is crazy to people. If you’re there for >5 years and then look for something else, interviewers wonder if something is wrong with you.
Which is insane. Companies lose a lot of value by not having long tenured “company [wo]men” anymore. I keep waiting for some convoluted explanation that shows this situation is better in even a strictly capitalist sense, but that explanation doesn’t seem to exist. The best I have is that people coming from outside organizations will cross-pollinate ideas and technologies instead of being stuck with whatever that particular company is doing. But there are other ways to handle that, and you don’t have to push it on everyone.
No, companies just seem to have decided this is how they’re going to operate.
It’s often either mentality or high workload. Higher pay will not help in these situations. There are bad corporations and also bad workers.
My thoughts on it are: as a developer, if you flag the issue for your management, and they want to move forward, then you’ve done your part.
Maybe put an extra comment in the code for posterity’s sake.
It’s not ultimately your problem and what else are you going to do? Work unpaid nights and weekends to fix it for some guy who might run into a problem 8 years from now?
My uncle was in that story. Decades ago, he told his boss a program would stop working in eight years (8-bit limitation, yeah, that long ago). His boss told him to ship it because they weren’t going to be there in eight years. Sure enough, they weren’t. Eight years later, their IT guy contacted my uncle because he couldn’t figure out why it stopped working, and my uncle showed him the math.
Sounds like your uncle did end up working for the company again, if only for an hour or day.
Hopefully at a really high hourly rate!
I’d do it just to style on the new guy, start with something like “ah, so humanity has lost the skills that we possessed in the days of yore…”
(TL note: this is in reference to companies refusing to up the pay for their skilled workforce, and ending up paying more to new guys that’ll have to learn it all from scratch)
Blame whoever implemented it if you want, but 9 times out of 10 it’s management that’s pushing for a quick fix.
Nah, more senior devs often also advocate for the quick fix, for the simple reason that the economics of a “proper” fix simply don’t add up, especially when you don’t know how much value such a fix would bring anyway. If you’re always looking to create “proper” solutions in hopes of someone in the future thanking you for it, it most likely means your priorities aren’t where they should be and it’s very unlikely someone will thank you for it.
I even wrote a blog on this topic: https://arendjr.nl/blog/2023/04/mvp-the-most-valuable-programmer/
“upper management written all over him.” - one of the Bobs
I was too slow but the CIO praised my code quality.
