New hires have trouble understanding that, occasionally, we have a valid business reason that a piece of code simply must EXIST. Yes, almost always, we want the code to exist and also be correct, or maintainable, or have other desirable properties. But not always. Sometimes the customer, or our own upper management, is completely fixated on the distinction between THINGS THAT EXIST and THINGS THAT DON'T EXIST. The worst possible day is when I hear back from the programmer about their perceived "progress" in which they have "evaluated design alternatives" or "better understood the problem."