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
[+] -26 points 6 months ago (8 children)

I would immediately fire somebody with such a mentality. Letting bugs live in production just to prove your point, that's borderline criminal. I get you're not happy with the vibecoder's job but there are other, smarter ways to deal with this than sabotaging the company.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 15 points 6 months ago

    Gunna be honest, if you really feel that way you'd fire the vibe coder. I don't give a shit if it's broken ifs due to the negligence of management and other employees.

    Poor planning on your part does not constitute an emergency on mine. And ofc this varies based on the service as all things do. But it's rarely important enough that I'd stay over. Like if lives where at risk or it's a "bring the company down but" maybe I'd stay. But there would be hell to pay for whoever broke it later. Either that or the company would loose me as an employee

  • permalink
  • fedilink
  • source
  • parent
  • [–] 13 points 6 months ago (2 children)

    By that logic wouldn't you be firing the vibe coder for not rolling back the commit?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •