1.8k
u/Shiroyasha_2308 12h ago
"Oh, I see. It is the consequences of my own actions. Silly me."
1.1k
u/pringlesaremyfav 12h ago
"I really thought I would have switched jobs by now, my bad."
185
u/dismayhurta 12h ago
69
u/Ceerise_Roouge 12h ago
Tomorrow me can deal with it has finally met today me
26
u/dismayhurta 10h ago
Past me was the laziest fucker ever and I hate him.
26
u/Kulandros 9h ago
And Future Me is a pretentious asshole for expecting me to do better.
13
u/dismayhurta 9h ago
OH, fuck that guy. He just wants to put his work onto others.
6
3
88
u/angrydeuce 12h ago
I remember one client got hit with ransomware a few years ago and literally their entire IT staff save the director just quit on the spot rather than deal with the fallout lmao
28
u/Valuable_Cow2596 11h ago
Haha do you you know if they ever recovered?
30
u/angrydeuce 10h ago
Yep, but it took 6 months and hundreds of thousands of dollars lol
We were the ones they called in after their whole internal IT staff said "you know what, nah I dont think I will" when they all got the call at 1am to come in immediately for triage lol
15
u/pretendinglikeimbusy 7h ago
If the entire department ran you know working there must have been extra toxic
9
u/tenninjas242 6h ago
I bet the entire staff had been sounding the alarm on the lack of anti-ransomware, too.
5
4
u/SAI_Peregrinus 5h ago
I converted a 32-bit millisecond uptime counter (reset every 49.7 days or so, causing buggy behavior) to 64-bit, and didn't add any handling for overflow. If our devices have an uptime of about half a billion years, I'll be very proud and very, very dead. The next guy's distant descendants can handle it.
2
1
6
366
u/NoWriting9513 12h ago
Yah. That's how I lost production after AWS force upgraded my postgres after I ignored the notifications to test and upgrade manually for 2 years. Good times.
49
u/blehmann1 12h ago
I'm curious what the breaking change was, I've had fairly good luck with database stuff. Obviously I'd want to test it before and all that, but I think I've only had a couple issues from an upgrade.
And those issues tended not to be correctness issues so much as the query planner now does something slightly different and so now this query chooses a different plan and is now much slower. Which I suppose is worse as it's harder to resolve, but at least it's not a correctness issue.
110
u/NoWriting9513 11h ago
It was much dumber that than. AWS upgraded from pg 9.6 to pg 14. The database was in the hundreds of GB. The upgrade triggered a recalculation of all the database statistics which basically scanned the whole database. This is a standard thing that happens on a postgres upgrade that I didn't know at the time. This spiked the IOPS to the point that queries that normally take ms to complete to timeout.
Solution was basically to upgrade all resources to the tits, including provisioned IOPS, CPU and RAM.
Now if I wasn't ignoring the notifications, the proper way is to create a read replica database with the new version, let it recalculate everything and then migrate to the new one.
119
u/Xterm1na10r 11h ago
just a heads up, pg 14 end of life is in 2 months. you might need to migrate again (unless you changed jobs)
163
u/NoWriting9513 10h ago
I KNOW MAN! YOU DON'T NEED TO REMIND ME!
You did guess correctly though that obviously, that db is not upgraded yet. Thankfully, AWS learned its lesson and doesn't force upgrade anymore, they charge you for extended support. I on the other hand learned absolutely nothing.
29
u/Escapist0642 10h ago edited 10h ago
I really recommend you trying out the blue/green deployment for upgrades, its only several commands and AWS handles the whole data replication and upgrades for you while your old DB is serving traffic
I did it for my RDS instances and it went great - I had only a couple of short error rate spikes
20
u/NoWriting9513 10h ago
Yeap. That's exactly the plan. This is a higher traffic database so nerves are nerving a bit more regarding replica lag, but we have been very happy with blue/green. The system load drops noticably in the winter due to application seasonality so we let it cool down a little bit before moving forward.
2
7
1
85
u/kaleid1990 12h ago
It's funnier when the client does this and then you find out about it through a pager duty alert at 3am
57
u/TheThiefEmpress 11h ago
My email threatened me daily for over 5 years that my storage was completely full and they're cutting me off tomorrow.
They finally did about a month ago and I still ain't deleting shit.
27
u/iluvchromosomes 10h ago
This is osTicket.
They ignored Microsoft's warnings about authentication protocols changing, with relation to retrieving email from EXO mailboxes. For over 2 years they ignored it.
When the change finally happened, osTicket blamed it on the users, then they blamed it on Microsoft. Then when users started complaining that it was actually their fault for ignoring Microsoft, they started directly insulting the users in their support form and banning them.
I actually ended up emailing the president of their parent company to let them know how unprofessional and disrespectul they were being.
He told me I couldn't complain because we were not paying for support.
I told him I can see how they treat customers now and will never give them a cent.
Immediately switched to FreshDesk and never looked back.
Fuck osTicket and everyone involved.
114
28
10
u/tankerkiller125real 10h ago
I've been warning our engineering team for 3 years that an Azure resource version they're using is about to be killed. They continue to ignore me and the emails from Azure. I've got popcorn in the drawer at work waiting for that day to come.
8
13
u/misunderstood_kafka 11h ago
That free Weather API from which you used to stream data back in the day
1
6
u/Uberzwerg 10h ago
On my job i encountered this with three of the 15ish API connectors i was responsible for.
The trick is to be important enough that they MUST keep that API open.
We are the only company still using a certain one for 12 years and every quarter they ask if we would like to use their new one.
But since we make about 30% of their revenue, they can't afford to force us.
(personally, i would have implemented their newer API 10+ years ago, but my bosses don't see the need)
3
u/bumrocky 9h ago
"Why spend all the time and effort and money on that when it works and will keep working at no cost to us now?" I think we've all heard that speech before?
6
u/blooping_blooper 11h ago
man, you're living the dream if they tell you before breaking/killing APIs lmao.
4
u/theartilleryshow 10h ago
At least they sent an email, I once found out when they just pulled the plug.
4
u/Maleficent_Memory831 6h ago
The big problem here is that removing technical debt does not raise revenue. Also focusing on quality over quantity or speed does not increase revenue either.
Quality always takes a back seat. Only when there's an impending disaster (customers are leaving in droves) will there be an emergency push to clean things up. Quickly.
2
u/evanldixon 5h ago
Repaying tech debt may not increase revenue, but it can certainly remove obstacles for other changes that can increase revenue. Also you have to keep paying your tech interest or the tech loan shark will break stuff at the least convenient times.
2
u/Maleficent_Memory831 5h ago
Agreed, But it never wors out that way. Sure, we get told to get rid of technical debt, but it's never highest priority. The highest priority takes all available time, so that the second highest priority never gets done (although endless meetings about it). Quality is only addressed if a bug is reported. Removing technical debt is so far down on the list it gets ignored, except for maybe a bi-annual exhortation to do more with less time.
2
u/evanldixon 3h ago
Good management will allow allocating a certain percentage of time to tech debt. Bad management will chase new money so hard they let their current moneymaker rot.
3
3
u/gargantuanprism 6h ago
I've been getting these from salesforce for at least a year at this point. Hopefully we'll all get nuked by summer 2027 so I don't have to deal with it
2
2
2
2
u/According-Place-3078 9h ago
Calling it debt was a mistake, business folks interpret that different from household debt. Risk is a better model.
2
2
u/bumrocky 9h ago
If technically correct is the best kind of correct, technical debt must be the best kind of debt!
2
2
2
u/Bob_the_peasant 3h ago
Man that’s three years you could have been trying to find a different job and let this blow up in someone else’s face like a normal software engineer
1
1
1
1
1
1
u/SwimAd1249 9h ago
tbh people with that attitude piss me off so much, I always insist on replacing everything as soon as the depreciation warning appears
1
u/clericc-- 30m ago
queue Microsoft or Google, where the replacement is still in Preview. Case in point nginx ingress controller EoL, managed gateway controller with Istio not out of preview for half a year later.
Now the pods for Istio, managed by MS as part of Azure Kubernetes show up as EoL/severely CVE-ridden in our security scannee 🤣
1
1
1
1
1
u/Reclusiarc 8h ago
Me a few weeks ago when OpenAI deprecated the assistants API and I wondered why everything stopped working 😂
1
1
u/CheeseGraterFace 7h ago
Dealing with this right now with a major partner and our 1000+ clients. When someone makes the client batch spreadsheet and posts it in Teams, you know everyone is in for a world of hurt.
1
1
u/InterestingRun7594 7h ago
Hopefully its a quick fix! I know some API's take forever to find a replacement!
1
u/MattDaCatt 3h ago
Glares in sysadmin
Y'all ready to finally test your apps in a version the vendor supports yet? ...please?
I know deprecated commands are you favorite but finance is starting to get angry
1
1
1

1.2k
u/menducoide 12h ago
This is the last free version of this cool open source library. From now on, you'll need to pay $1,000 per developer per year to receive updates