[hiq]

It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do?

I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all?

But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.

[Hizonner]

> If I start working on an existing codebase, the warnings might be there already. Then what do I do?

What would you do if the code you inherited crashed all the time?

Come up with a strategy for fixing them steadily until they're gone.

[hiq]

If this code crashed all the time there'd be a business need to fix it and I could justify spending time on this.

But that's not what we're discussing here, we're discussing warnings that have been ignored in the past, and all of a sudden I'm supposed to take the political risk to fix them all somehow, even though there's no new crash, no new information.

I don't know how much freedom you have at your job; but I definitely can't just go to my manager and say: "I'm spending the next few weeks working on warnings nobody else cared about but that for some reason I care about".