[dude250711]

> It was a slog, and it also made me look bad because it took me forever compared to the team who originally churned it out almost instantly.

The hell you are playing hero for? Delegate the choice to manager: ruin the codebase or allocate two weeks for clean-up - their choice. If the magical AI team claim they can do integration faster - let them.

[jcgrillo]

IME one thing that makes this choice a very difficult one is oncall responsibilities. The thing that incentivizes code owners to keep their house in order is that their oncall experience will be a lot better. And you're the only one who is incentivized to think this way. Management certainly doesn't care. So by delegating the choice to management you're signing up for a whole bunch of extra work in the form of sleepless oncall shifts.

[johntash]

If someone is making the kind of mistakes that cause oncall issues to increase, put that person on call. It doesn't matter if they can't do anything, call them every time they cause someone else to be paged.

IME too many don't care about on call unless they are personally affected.

[chii]

> If someone is making the kind of mistakes that cause oncall issues to increase

the problem is that identifying the root cause can take a lot of time, and often the "mistakes" aren't clearly sourced down to an individual.

So someone oncall just takes the hit (ala, waking up at 3am and having to do work). That someone may or may not be the original progenitor of said mistake(s).

[jcgrillo]

Framed less blamefully, that's basically the central thesis of "devops". That is the notion that owning your code in production is a good idea because then you're directly incentivized to make it good. It shouldn't be a punishment, just standard practice that if you write code you're responsible for it in production.