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."
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.