What if the guy who takes 5X to do the work has less bugs and more efficient code and secure code? just because you code faster doesn't mean your code is better, in fact it is probably worse, because you didn't take your time.
I'm merely saying that the speed you produce code is not directly related to it's quality. Release early and often does have it's merits. But that doesn't mean whip code out in an hour, and then fix bug after bug after bug.
That's the point (even inferable from the title) - he'd take a good programmer who was slow (like you describe) over the bad programmer, who is slow, and writes bugs, and takes a long time to fix those bugs, and makes more work for other people. Fast good programmer > slow good programmer > fast bad programmer > slow good programmer.
Accidentally hit the up arrow instead of the down, so I will respond.
His bug tracking/pm software is actually quite good. He doesn't actually write software anymore from what I understand. And attacking him personally doesn't change the validity of his point.
How did I attack him personally? I didn't say he was stupid. I just don't like his ridiculous, impossible elitist attitude towards hiring wherein, if you take him at his word, approximately no one is good enough for him. Talking about famous works of high art when you make your living off server-side software that integrates email and version control through the browser is ridiculous, too.
The lesson of his business is that you should try to produce boring, solid software that solves problems in a very simple, straightforward fashion using a handful of good ideas (maximize the probability of getting bugs in by, e.g., not having any required fields; prevent the improper use of metrics by not adding much reporting functionality). He has long, old release cycles that ensures polished, stable software. This is not rockstar genius ninja work at all.
The Javascript wankery that's far beyond the capabilities of typical code monkeys (the spellchecker, dragging and dropping columns in tables, etc) is the least valuable part of FogBugz.
This guy went to the trouble to gather data, chart it, try to show his readers something interesting, and your response is, "He produces dull, reliable software, so he can't know anything about who is a good software engineer."
You did not address his point, the validity of his data, or his reasoning. You simply said that his argument is not valid because of who he is and what he does for a living.
Maybe if you'd said something like, "To the extent Spolsky's essay implies that Fog Creek is a place where geniuses crank out the Requiem of software on a daily basis, I disagree because X, Y, and Z," it might not have come across as an ad hominem attack on his point about the differences between good and bad programmers. Frankly I don't think many YC readers care about Fog Creek -- they're here for the more fundamental wisdom about programming.
I think one point thats worth pointing out is that in a lot of Spolsky's opinions regarding whats good and bad CS seem to be highly influence by the fact that he couldn't cut it in terms of theoretical computer science coursework back in college, or at least thats the sense i get from his writings....
Your response is DH1, attacking the writer, not the message. Too bad.
I don't know Joel and I don't know how good is software or business is. I DO KNOW that this essay is a real saver. It's what I hand clients who question my rates. It shuts them up every time.
At what point did I call him a name? What name did I call him?
The boring database frontend/service integration software that keeps Fog Creek afloat is not a symphony or other work of high art and the analogy simply does not hold water.
Basically to sum it up, the author mentions a very simple question that he asks potential programming candidates to solve. This kind of question is the kind of question you can solve by making it through two/three chapters in any programming book, yet the number of people, even senior level developers, that can't get it is astonishing.
I remember that article - I quickly reassured my self by writing fizz-buzz in Perl, Ruby and PLSQL (my three most used languages) - no great achievement, but I am better than the majority of comp-sci grads apparently!
I'm merely saying that the speed you produce code is not directly related to it's quality. Release early and often does have it's merits. But that doesn't mean whip code out in an hour, and then fix bug after bug after bug.