Clients and fellow programmers are still happy with your work two years after you've delivered it.
(Of course: "still" implies that they we're happy at delivery, which includes actually shipping working software in a timely fashion.)
Disagree. The first system I wrote kept the client happy for years. It was a mess, but it was literally millions of dollars better than not having any system.
If what you mean is something like "focus on doing work of long-term value, and consider programming skill as such an input", then I'd agree with that.
Did your client ever hire programmers to maintain and improve the first system you wrote? Were those programmers happy with your work?
I guess if no one is ever going to maintain your code it doesn't matter as much. I wouldn't ever be so bold as to predict ahead of time whether that's going to be the case.
Can a mediocre programmer tell the difference between mediocre code and good code?
To the original point, the happiness of the client and other developers is a good indicator, but not the only.
The maintenance programmer should be competent, but shouldn't have to be brilliant to understand what's doing on (except in the rare case that your code actually is doing something brilliant). If the maintenance programmer doesn't understand a basic language feature, it's his fault if he doesn't understand your use of it (be it ternary operators, blocks, list comprehensions, regular expressions...). If the maintenance programmer does understand ternary operators but you do something like nest them four layers deep, it's probably your fault if he gets lost.
Can a mediocre programmer tell the difference between mediocre code and good code?
* Disclaimer: maybe I've seen so many "you're doing it wrong" posts that I see something in the opposite direction and get too excited.
But then, that's what makes something like PG's "Great Hackers" (http://www.paulgraham.com/gh.html) rare. It takes a lot of things: education, some innate ability, good habits, work environment -- including a good team...
Innate ability isn't a huge factor, but writing wonderful code definitely isn't for everyone. So then, what is to be done with all the mediocre code being produced? I don't see the world overrun by it, long term: code is too expensive. But to get there, something definitely needs to be done.
I've cooked meals for people that were impressed and happy, does that make me a great chef? Perhaps the people I fed are easy to please, have a simple tastes, spend most days eating unflavored oat meal.
If i'm capable of changing a car's spark plugs, and it continues to run well does that make me a great mechanic?
People having low or incorrect expectations does not change the overall quality of something you create or deliver.
Ignore those.
That being said, if you are in a team and you know you all will have to extend or maintain the code at some point, then discussion of coding style, program features, choice of data structures, etc, is healthy. These things are important for a growing application, getting them right will make the software more robust and make maintenance more efficient.