Agreed. A programmer maintaining a new project is going to feel frustrated when the application cannot be easily extended in a way that they expect, but the original author should be forgiven for not predicting every possible future permutation of their existing code base. The best design decision might seem obvious from the maintainer's perspective, but given 100 different maintainers, you'll end up with 200 different solutions, half of which will make the original application seem ridiculous when framed in the context of a massive rewrite that takes into account every business decision that time and experience has yielded since the start of the project.
Further, there are times when a good programmer must deliberately exclude forward thinking solutions because a non-functioning product precludes a successful business. Yes, it should still be a secure solution. Yes, a TODO label may be warranted, but a surefire way to get yourself labeled as a bad programmer is to spend weeks working out "future proof" solutions while the competition is shipping an application that can be successfully executed.
Though there are some good points here, my experience has been that this "just get it done" above all else principle has sunk just as many projects as it has launched.
Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion.
It is completely ridiculous to say as long as one can get a product launched, they are a good programmer, because you're likely praising a group, half of whom are good programmers, and half of whom are sinking the product more and more over time. This is a common happening I see with praise of engineers from a management perspective, and why so often companies sink without knowing where exactly they went wrong.
You can judge if a programmer is good, not by tearing apart and poking at the mistakes they made in a new project, but if they proceeded to code using strong abstractions and decoupled code. The easiest programmers to fire are the ones who don't ship, and the programmers that tend to be the costliest to a business are the ones who ship crap code.
I didn't say above all else, but I take your point. Of course, this is a balancing act, and I suspect we're both facing some selection bias, but I have to disagree that creating maintainable code is necessary for being described as a good programmer. At the end of the day, all programs are maintainable, as long as the source can be read and understood by a programmer. There is a huge advantage to having a well designed application structure, but there is no replacement for an application that meets its functional specification.
I would replace your "Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion." with, "Getting it done is a bare necessity of a good programmer, but what separates the great programmer from a transcendent programmer is whether they get it done in a more maintainable fashion."
Further, there are times when a good programmer must deliberately exclude forward thinking solutions because a non-functioning product precludes a successful business. Yes, it should still be a secure solution. Yes, a TODO label may be warranted, but a surefire way to get yourself labeled as a bad programmer is to spend weeks working out "future proof" solutions while the competition is shipping an application that can be successfully executed.