As a first-year programmer a project manager said to me, "I've never heard a programmer praise another's code. It's always, 'This is crap!'" So I always try to be slow to criticize. There is a lot of crap, but things might not be as simple as you think. I really believe we should take more time to read and understand before we write. Or think about G.K. Chesterton's fence:
Oh no, I always get rid of stuff I don't know why it's there.
Because if it does not break when I run "make check", it's not covered by the testing and it shouldn't have been there in the first place anyway.
And if it had a use for someone, but nobody knows, removing it is also a very efficient way to figure out :)
This all depends on the nature of the business, the app, codebase, customers, processes of dev/QA/ops, etc. For example, this cavalier attitude might work at a social media startup but not at a bank.
Thanks for posting - I hadn't really considered Chesterton's Fence as a technical metaphor but as soon as you posted I immediately thought of a person who has a habit of this very act. I'm adding this term to my lexicon.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there!