Remember, always, immediately, push new updates to prod, specifically right before you go home at the end of the day.
this post was submitted on 18 Sep 2025
298 points (99.0% liked)
Technology
75411 readers
1823 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
Double points if it's friday
Triple points if you're going on a month-long holiday.
We've all done it. ...right?
That's how we know not to do it anymore
Knowledge tells you it's safe to push to prod in Fridays. Wisdom tells you not to. Experience raises your heart rate at the very thought (though, that might actually be ptsd)
My favorite personal fuck up was when I accidentally locked myself (and literally everyone else in the company) out of the CRM I was working on by disabling the login pages and enabling SSO before I had finished setting up the SSO inside the CRM's config, and it logged me out as part of the procedure. Whoops.
I think most people have done, or been part of a team that did, something similar.
At least most of the engineers I've worked with have had similar stories from their past
Idk most teams I've worked with have either known better than to deploy anything at EOD or on a friday, or make heavy use of feature flags so any change that caused an issue just got swiftly rolled back. The ones that didn't, I made it ABUNDANTLY clear that I won't be available outside of work hours.
Maybe I haven't been around the block enough or maybe I got lucky...
Probably depends on the type of company you work in. If it's a long established one with lots of staff, they've probably realised this issue a long time ago and put plans in for it.
If it's a more modern one that hired a bunch of solid old heads early on, they probably know better from the outset.
In both cases, someone, somewhere will have probably experienced it and said "never again", so implemented (or improved) release procedures to ensure it doesn't happen again
A lot of my teams have been on the younger side and for small companies/startups. So everyone either had a recent example to pull from or had first have experience
That is what CI is for Commit Incident.
And CD is for Commit Disaster
Bonus points if you do it the day before you leave for vacation!
Ah, a true chaos wizard, I see.
The DDoS came from ... INSIDE THE HOUSE!
You'd be surprised how often DDOS can be an inside job.
Glares at marketing department
Marketing is just the sabotage team in disguise
Not surprised at all actually. I've done it. 😬
glad to know it's not just me
Finally, a DDoS that even Cloudflare couldn't stop
CloudFlare stopped the DDoS by destroying their own servers.
“I’ve won, but at what cost?”
I recently ran a session and wrote an internal blog post about why useEffect was a dangerous crutch that should be avoided wherever possible. This was due to recently experienced over-complicated logic and unexpected interaction bugs.
This is a little different but I still feel vindicated.
You are correct, useEffect can be dangerous if you don't know exactly what you are doing. I would go so far as to say that most people use it incorrectly. This includes myself, I am not great at using React and end up using it in the wrong places, which according to a colleague, it should just be avoided if possible.
Clownflare staying true to its name.