>But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.
So, the perfect programmer is a better programmer? That goes without saying. I think his post is more an issue of people who build things vs. people who can code algorithms. Personally, I'm the former and as such naturally think it's superior. Let's face it, we can't all be perfect programmers.
There's the developer who can register a domain, set up a LAMP server, get a web application up, create a good database schema and make it look nice and do it all in a weekend. Then there's the programmer who will come in and look at one portion of a less-used paged and call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n).
It depends on what your focus is I suppose. The question is whether or not I (or the author of the article) would be able to optimize that chunk of code if the user experienced slowness.
My point is that quality is an objective measure which does not depend on situation, or reality, or getting things done, or time constraints, or personal issues, or whether you do it in a weekend. Better code is still better regardless of all that.
You have to have an objective notion of quality before you go trying to apply it to reality. And if you do, you might have a chance at improving it.
Well, you're simply incorrect. I mean, we can agree what a perfect programmer is. But comparing the qualities of two imperfect programmers is absolutely situational, just like any skill. Who's the better athlete, Michael Jordan or Michael Phelps * ? They're both great athletes, but who's better? I guess you could have them perform in every olympic event, but that wouldn't really tell you much.
Ah, but I just noticed a small syntax difference in your argument. You're arguing about better CODE not better CODERS. Still arguable, but more objective. You can easily gather a lot of metrics about code. Still, if I'm programming something for my graphic designer sister to work on later, I'm going to program differently than if I was writing a compact and efficient internal piece of code.
You're absolutely right, there are differences between situations. I absolutely, positively know that.
But I'm saying, when you're measuring quality objectively, it just doesn't matter. What matters is the thing itself. The created object. The outcome.
I'm not simply incorrect—I'm simply correct. My argument has the constraint of simplicity. It is defining the basic existence of a thing which we know exists, namely Quality. When you add complexity, yes, the definition is no longer sufficient to describe the entire process; but I'm not claiming that perfect code and perfect coders are possible in reality. I'm saying: start with simple and true definitions so you understand what quality is by itself, so that once you add situations and reality to it you can still try to achieve something close to "good." It is a matter of scope.
This isn't an argument. Quality exists. Defining it is hard, yes, but it's not impossible to understand that one thing can be better than another by many measures, and we say that thing has higher Quality.
Read "Zen and the art of Motorcycle Maintenance," it'll twist your brain up some more.
What you're going to say next is of course that you're right and that devolving into silly philosophical arguments doesn't mean anything to real-world work, so yes, I guess I'll agree with that.
>call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n).
Nope, they'll call you a shitty programmer because every function in your codebase depends on the interface of every other function. Then they'll charge you a fortune to fix it.
And then as soon as they are done fixing it the requirements change and the fancy decoupled codebase (while very flexible in serving the needs of the old requirements) is basically non-workable for the new requirements.
But registering a domain and setting up LAMP servers are not programming tasks. I think there can be a name for that (maybe "product builder"?), but it doesn't make sense to co-opt "programmer" for it.
So, the perfect programmer is a better programmer? That goes without saying. I think his post is more an issue of people who build things vs. people who can code algorithms. Personally, I'm the former and as such naturally think it's superior. Let's face it, we can't all be perfect programmers.
There's the developer who can register a domain, set up a LAMP server, get a web application up, create a good database schema and make it look nice and do it all in a weekend. Then there's the programmer who will come in and look at one portion of a less-used paged and call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n).
It depends on what your focus is I suppose. The question is whether or not I (or the author of the article) would be able to optimize that chunk of code if the user experienced slowness.