this post was submitted on 11 Mar 2026
135 points (97.2% liked)

Programming

26022 readers
320 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
135
Dealing with YOLO Vibelord colleagues (lemmy.world)
submitted 1 day ago by reabsorbthelight@lemmy.world to c/programming@programming.dev
38 comments fedilink hide all child comments
 

So my manager today asked me if I could stay later when there's broken things in prod, and then today his star dream employee yolo'ed a full stack change into prod without review. It's fucking massive and implements new API endpoints, touches >20 files. Many of the diffs are too large to render in the browser.

It's almost comical, but something immediately broke.

Most of my day, I'm digging through code to identify bugs created from this shit, just to get a stealth merge midday.

I kind of don't know what to do.

you are viewing a single comment's thread
view the rest of the comments
[–] mesamunefire@piefed.social 4 points 1 day ago (1 children)

Make ci/cd part of the process. It stops a lot of people who push huge unmaintanable changes.

If it doesent pass the tests and cant build then it stops them from merging.

[–] reabsorbthelight@lemmy.world 1 points 1 day ago (1 children)

Yeah this is my general tool for dealing with shit code. I'm currently working on getting that into the CI

[–] mesamunefire@piefed.social 2 points 1 day ago* (last edited 1 day ago)

It helps! Ive seen it with two jobs completely change the culture around code review.

  • Instead of you/team lead being the bad guy, its now the code/process.
  • Code becomes more stable and releases actually become more frequent.
  • If something goes wrong, your VM/docker/box/etc.... can just be re-spun up by the same process.
  • Easier to onboard since the same build process is in the CI. And is constantly being used rather than relying on the README (that may not have been updated in a while).

Mind you its not perfect of course. You can still "Vibe" test and/or remove tests that dont work. And make the project more brittle. Or go overboard with lint rules (I actually had to break up a fight with that one). But its much better than the old process of merge and pray.