Programming

Don't provide bailouts for neither your manager nor your colleague. Highlight as far up the chain as you can the damage their behavior is having on the business.

Do NOT under any circumstances fix it. The other guy needs to and you need to be clear he broke it and how

You need SRE concepts. First, if you break it then you fix it; in a system where anybody can make a change, it's the changer's responsibility to meet service objectives. Second, if your boss doesn't find that acceptable then they need to appoint a service owner and ensure that only the owner can make changes; if the owner breaks it then the owner fixes it. Third, no more than half of your time should ever be spent fixing things; if something is constantly broken then call a Code Yellow or Code Red, tell your service users that you cannot meet your service levels, and stop working on new features until the service is stable again.

Under no circumstances, ever, should anybody stay late. There should only be normal business hours, which are best-effort, and an on-call rotation which is planned two months in advance. Also, everybody on call should be paid hourly minimum wage on top of salary for their time.

I would say no to staying back. The employee that broke it needs to fix his code, at the very least roll the change back.

At the next meeting or post mortem bring up why code can be pushed to prod without review. Your git forge should be able to block merging to prod by a single person.

Roll it back and go home.

Pushing to prod without review and breaking the running application is a resume-generating event in many companies. In many others it's not even possible because of programmatically enforced policies.

If your company's response is not to prevent or dissuade it but to have other people work overtime to fix the mess then that's a major management fail.

Try to educate your boss about best practices. This incident should give your arguments some more weight.

Deployment to prod should not be something a developer can do by themselves; a proper CI/CD system can be configured so that prod can only be deployed to by people with an appropriate role (product owners or lead devs if your company doesn't have POs).

If you don't have such a system, make it an explicit policy: Only Steve the lead dev (or someone specifically appointed by him while he's absent) can push to prod; if anyone else does it they get invited to an uncomfortable meeting with Steve. If they do it again the meeting will be with HR.

But seriously, you should lobby for a proper CI/CD system (if none is present) and for the system to be configured so that a) you can't merge to the main branch without a code review and b) deploying to prod only works from main and with explicit approval by a PO/lead dev. That should stop most of the shenanigans.

Roll it back and go home

If your manager won't hear anything negative about Vibelord, polish up your resume. There's nothing you can do to change the culture of your team if the boss isn't on board with it.

Not sure what kind of person your boss is, but if you want to try to win him over, try to figure out what might sway him. If he's technically illiterate, talk to him about best practices (like, I dunno, code reviews) and cite reliable sources and data if you think that would help. Avoid calling out Lord Vibington, the main thing is to put a picture into your boss's head of what this could/should look like. He might not realize that these issues are preventable.

The goal here is to get your boss to take more ownership of the team's culture, and start insisting on preventative measures. Mr Viberator will either have to conform, or there will be increasing friction between him and the boss.

Explain to your manager that if an employee can merge code without reviews, he should expect breakages on regular basis.

Propose that your team can meet to talk about how to make the process better, so no breakages occur.

Mention personal responsibility and knowledge - it’s a good practice that a person who wrote the latest code changes either helps either is responsible for making the service working again, if there are issues - specifically because they might have some idea what’s broken.

If your manager will ignore it, I’d start looking.

Changes that big need to be broken down into smaller PR-sized steps. To do that you need an actual plan of how to get from here to there. Bro is swaggering like a senior then coding like a junior.

What to do? Well now you have evidence that AI tools are not yet good enough to write code that doesn't need human review before deploying to prod. Chat with whoever is in charge of Process, and get some team guidelines in place to prevent unreviewed code going to prod, and unreviewable PR's being submitted for review.

You render diffs in the browser?

And no, let the yolo fix the things he broke, or he will never learn to be a responsible coder.

I'd just talk to the guy, clarify HE needs to stay late not me, then log off. If he's nice about it I'd consider ataying but from your description, he's anything but.

What you gotta do in situations when someone is beingan asshole is spark a meeting with the higher ups so they can see the BS you deal with and how it's none of your business that prod was messed up.

This is not how you do development. Like, at all. If changing jobs is an option for you do it. If not, well, not much you can do. You're not going to fix the entire company if management and other devs don't know how it should work and don't want to change.

Pray that the whole system breaks sooner than later...

if I could stay later when there’s broken things in prod

In general, or on this instance?

Do you have team retrospectives? That's where I would bring it up in my team. Raise my concerns, explore and understand what team consensus is around this topic, around risks, quality, etc.

If the team consensus and/or management consensus is YOLO - then I try to protect myself from personal investment and going beyond contractual obligations. Because I already know what will come and how it will negatively affect me personally.

It's possible a honest discussion with management about goals and risks could lead to clarified guidelines, requirements, and goals. If it doesn't, I'd probably be looking for a better job/environment. Because I'll be miserable if colleagues YOLO, no matter how careful I am personally.

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.

When Rome is burning, do as the Romans like Nero do. Fiddle a nice tune, tell Claude to fix it for you, and go home. If they're not willing to give any fucks, why should you?