For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.
Agree. It helps to cut your software-chops or steer yourself into an industry where software is an overhead, rather than the main product (said in the best possible manner).
For example, controller software attached to a turbine engine. What I said above is especially true in those scenarios and is actually quite folly to do more than necessary in the name of software perfection. Plus unnecessary complication hurts brains :)
We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid).
The distinction has to be made between good software and well-written software. It is very possible to have well-written bad software and awfully-written good software.
I think realising this, is what makes a junior into a senior. Having the confidence to not always do what that little birdy in your head says :)
Customers buy software that solves problems, therefore good software solves problems. Customers buy good software, not well written software. These are not always mutually exclusive.