You must log in or # to comment.
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
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.
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 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?
It’s a balance, but too many people don’t even flag it to management because they’re lazy and they write shit and ship it to get it off their own plate.
Now, if management says ship it anyway it’s a balance of you as a developer making sure they understand they’re throwing this technical debt on the credit card and it may (probably) need to be paid off later. If you fail to articulate the interest that’ll be due later then you didn’t do enough or management is bad.
You shouldt work unpaid to fix it, but sometimes you should just do it right even if it takes longer because it’s how it should be done.
So comment it with //this function fails here if clientCount >20 000 000
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)
Nah. Everyone knew everyone back then, and my uncle loves sharing his stories. Basically all he did was tell that then-eight year old story, which still holds up.
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.
Maybe I’m a sentimental fool, but I feel like there should be some kind of basic respect for the craft, and doing things the right way just because. I get making bad code to meet a deadline, but not if you have a choice.
Then again, I’ve never done coding as my main job.
I have done it as my main job and I echo your sentiment. It’s inevitable that sometimes you have to meet a deadline or get something more important working first, but if you write bad code because you are lazy or unwilling to read the docs to do it right, shame shame shame.
Some people just don’t care. To me it really feels like they are trying to create the problems to later sell the solution, and it’s a never ending cycle. I’ve quit my recent job because 90% of the team just sucks, security risks everywhere, the API just doesn’t respect contracts, there’s no contract actually, we just ask on private chats how to integrate with it really. New features on top of buggy code while support is on fire with the 100th bug ticket reported in just a week. Not to mention that you have a design team, a project manager and a “VP of engineering” but the epics they want you to do are almost just the title of the idea they had at lunch 😅.
This guys are very lucky because the operation teams is able to cash in millions of revenue a year by combining excel, monday and WhatsApp to do their jobs, while a few are still forced to interact with a piece of shit of software that the engineer department provides to them…
Anyway, some people just don’t care.
We do. We make the best we can in the time we’re given. People say “minimum viable product” but we never deliver that
Can confirm - you work like a dumber, more tired version of you needs to maintain it, so comment accordingly. Also, you do the work right but also fast; and you see how right you can do it in a reasonable timeframe of course.
But we fired a lot of our mentors after Y2K to save money that quarter. And the juniors there had no learning as to the whys of the whats when it comes to best practice. Those juniors became seniors and their juniors are 2nd-gen flying blind. We’re doing dumb things because we know why we shouldn’t, but we don’t understand that we shouldn’t. (Hint: if someone says “Yeah But,” they may not get it)
We need to rediscover the whys we lost; and it’s gonna be hard to really understand it, but we’ll figure it out. A few more ClownStrikes and we wont have a choice!
Yeah but, move fast and break things is management’s motto, they don’t want to pay for the time it will take to write good code
In capitalism, creating problems keeps people employed.
If your shit’s maintained and running perfectly, it looks as if you’re not doing anything.
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
deleted by creator
And here I am, working for the same company for over two decades 🤷
deleted by creator
hey, congrats! :-) have fun with your extra free time!
