Or are you only considering a certain warnings?
Well, it wasn't my codebase yesterday, because I didn't work here.
Today I do. When I build, I get reports of "pkg_resources is deprecated as an API" and "Tesla T4 does not support bfloat16 compilation natively" and "warning: skip creation of /usr/share/man/man1/open.1.gz because associated file /usr/share/man/man1/xdg-open.1.gz (of link group open) doesn't exist" and "datetime.utcnow() is deprecated and scheduled for removal in a future version"
The person onboarding me tells me those warnings are because of "dependencies" and that I should ignore them.
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.
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.
2 Years later, you have hundreds of warning.
If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.
