167
Dealing with YOLO Vibelord colleagues (lemmy.world)
submitted 6 months ago by to c/programming@programming.dev
48 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
[–] [S] 1 point 6 months ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 6 months 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.

  • permalink
  • fedilink
  • source
  • parent