I think there is some confusion over quality vs. quantity.
You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre.
Quality is independent of quantity or productivity. You may choose to lower your quality in favor of a higher rate of productivity, but you've still lowered your quality.
So you may be a productive programmer. But that doesn't necessarily make you a good one.
There's also the matter of the quality of code that your'e capable of, versus the quality you actually produce. So you may be a very good programmer forced into producing shitty code (time constraints often do this).
But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.
>You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre.
The code might be mediocre, but that doesn't mean that the product is mediocre. Pristine, beautiful code, that forms part of a bad product, is like a soprano singing the most god-awful piece of bilge anyone has ever heard. Doesn't matter how good her voice is if the song is rubbish and makes everyone cringe.
>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.
I think quality to some degree is subjective in programming though. A lot of coders these days focus on beauty or fancy data structures instead of writing clear, straight forward, efficient code.
Most of the discussions of beautiful code that I've read are about how clear and straight forward are perquisites to beauty. Code that's difficult to understand or reason through is almost always described as ugly. Efficiency is normally impossible without using the right data structures.
I'm not clear who you're complaining about here. It's possible you're complaining about yourself.
I certainly didn't mean it as a personal attack, and am sorry it came off that way.
I was trying to say that it if the parent writes clean, clear, and efficient code, it might qualify as the sort of beautiful code that people are striving for.
A good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.
I think you just shifted the problem of defining a "good" programmer to defining "high quality" code. Some people might argue that the code that gets the job done most efficiently has the highest "quality".
You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre.
Quality is independent of quantity or productivity. You may choose to lower your quality in favor of a higher rate of productivity, but you've still lowered your quality.
So you may be a productive programmer. But that doesn't necessarily make you a good one.
There's also the matter of the quality of code that your'e capable of, versus the quality you actually produce. So you may be a very good programmer forced into producing shitty code (time constraints often do this).
But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.