572
Developer stages of grief (kbin.melroy.org)
top 29 comments
sorted by: hot top controversial new old
[-] YtA4QCam2A9j7EfTgHrH@infosec.pub 105 points 1 year ago* (last edited 1 year ago)

If you can fuck up a database in prod you have a systems problem caused by your boss. Getting fired for that shit would be a blessing because that company sucks ass.

[-] fidodo@lemmy.world 51 points 1 year ago

What if you're the one that was in charge of adding safe guards?

[-] YtA4QCam2A9j7EfTgHrH@infosec.pub 40 points 1 year ago

Never fire someone who fucked up (again; it isn’t their fault anyways). They know more about the system than anyone. They can help fix it.

[-] raldone01@lemmy.world 14 points 1 year ago* (last edited 4 months ago)

This is the way usually but some people just don't learn from their mistakes...

[-] bane_killgrind@lemmy.ml 5 points 1 year ago

If you are adding guardrails to production... It's the same story.

Boss should purchase enough equipment to have a staging environment. Don't touch prod, redeploy everything on a secondary, with the new guardrails, read only export from prod, and cutover services to the secondary when complete.

[-] meat_popsicle@sh.itjust.works 9 points 1 year ago

Sorry, not in budget for this year. Do it in prod and write up the cap-ex proposal for next year.

[-] bane_killgrind@lemmy.ml 3 points 1 year ago

Yeah right? Offset via the cortisol of developers

[-] daq@lemmy.sdf.org 10 points 1 year ago

Small companies often allow devs access to prod DBs. It doesn't change the fact that it's a catastrophically stupid decision, but you often can't do anything about it.

And of course, when they inevitably fuck up the blame will be on the IT team for not implementing necessary restrictions.

Frequent snapshots ftmfw.

[-] mikyopii@programming.dev 85 points 1 year ago

I always run my queries in a script that will automatically rollback if the number of rows changed isn't one. If I have to change multiple rows I should probably ask myself what am I doing.

[-] assembly@lemmy.world 84 points 1 year ago

Damn that’s a good idea. Going to write that down, put it in the to do list, and regret not dosing it.

[-] takeda@lemmy.world 36 points 1 year ago* (last edited 1 year ago)

I always start a session with disabling auto commit (note, I could add it to my settings, but then it would backfire that one time my settings don't execute, so I'm making it a habit to type it out every time, first thing I connect)

BTW: what kind of genius decides that auto commit should be enabled by default?

[-] mikyopii@programming.dev 10 points 1 year ago

That's a good idea too. I'll have to look into that.

[-] SorryQuick@lemmy.ca 1 points 1 year ago* (last edited 1 year ago)

Or at least run it in the test database first.

Or run your updates/deletes as select first.

[-] marcos@lemmy.world 61 points 1 year ago

Don't you people have a development environment?

[-] nxdefiant@startrek.website 92 points 1 year ago

The P in Prod stands for "It'll be Pfine"

[-] marcos@lemmy.world 8 points 1 year ago

The letter you want after the P is an H.

[-] jjjalljs@ttrpg.network 81 points 1 year ago

There's that old saying 'everyone has a development environment. Some people are lucky enough to have a separate production environment, too'

[-] soggy_kitty@sopuli.xyz 7 points 1 year ago

I get you're making a meme but I've never worked anywhere that only has one environment in the last 10years.

[-] Unforeseen@sh.itjust.works 45 points 1 year ago

If he recognized his typo with the space after the D:\ in his restore command he could have been saved at the bargaining stage. I am so glad I don't work with this stuff anymore.

[-] fibojoly@sh.itjust.works 18 points 1 year ago

A few months back I crashed a db in prod. I detached it and when I tried to reattach it simply refused, saying it was corrupted or some shit.
Lucky me we have a backup solution.
Unfortunately it was being upgraded, with difficulties.
That was a long day.

[-] Korne127@lemmy.world 17 points 1 year ago

The famous onosecond

[-] corsicanguppy@lemmy.ca 15 points 1 year ago

emails

Yeah, don't hire that guy.

[-] NoLifeGaming@lemmy.world 11 points 1 year ago

Makes me think of what happened to gitlab

[-] jjjalljs@ttrpg.network 6 points 1 year ago

I have several times insisted that a migration be done via an ad hoc endpoint, because I'm a jerk, but also it's much easier then to test, and no one has to yolo connect directly to prod.

[-] soggy_kitty@sopuli.xyz 1 points 1 year ago

Endpoint? Why the fuck is a migration using an endpoint, if you want testability a script will do just fine

[-] jjjalljs@ttrpg.network 2 points 1 year ago

Because I didn't want someone to yolo connect to production, and we don't have infrastructure in place for running arbitrary scripts against production. An http endpoint takes very little time to write, and let's you take advantage of ci/cd/test infrastructure that's already in place.

This was for a larger more complicated change. Smaller ones can go in as regular data migrations in source control, but those still go through code review and get deployed to dev before going out.

[-] soggy_kitty@sopuli.xyz 1 points 1 year ago

You're definitely over complicating it and adding unnecessary bloat/tech debt. But if it works for you then it works

this post was submitted on 02 Mar 2024
572 points (98.1% liked)

Programmer Humor

34757 readers
308 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS