Don't assume I am talking about personal ROI. Team ROI is critical. Seeing a feature early so we can decide if the goal needs to be changed it valuable. Clean code that's going to be deleted tomorrow is not.

The 3rd time you touch a function is often a great time to make it awesome. However, a lot of code never reaches production and maintainability is more of an issue for code that survives.

Not just your coworkers today, "future you" as well.

I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.

If it worked for a year without bugs, then it's not garbage.

Did it work? Can you read and understand it? Then it has value.

Unless it had no users or it was so much garbage that nobody reported any bug.

PS: The goal of Windows is not to create an OS the goal of Windows is to make Microsoft money.

There is a lot of binary discussion here that treats code as either clean or not. Of course, it's always somewhere in the middle.

Finding the right line in the sand for your current job is an art. There is ALWAYS more you can do, and being smartly-selfish is inevitable.

I don't think the parent was talking about writing bad code. I think he/she was saying not to stress about writing good code too much. Those are different things.