"If their answer isn’t immediately and without any hesitation these two words: “My own,” then you should end the interview."

I strongly disagree with this. I've written some pretty bad code in my time. But that doesn't mean it's the absolute worst code I've seen recently.

At any rate, to make a long story short, I agree with reasons 1 and 7, but I'm not sure I agree with any of the reasons in the middle (especially #5). When you work for a software company, the code literally is your product. There's absolutely no difference between writing good code and delivering a good product. Therefore, you do need to put time and thought into it. That's not to say you need to spend forever trying to make it perfect. It's just that the "code isn't important, products are" meme is a false dichotomy that gets old after a while.

I think this is written from the standpoint of a web shop. Maybe there are more 37signals-ish shops out there than remains apparent; a great majority are dealing with tight deadlines, unknown factors, scope creep, etc.

Your great code gets re-written, stripped or worse on a split second decision the client makes. I'm not talking about fish-out-of-water clients, either. Big media clients tend to run their production like a fast food restaurant.

You're put in a position where you either get it done quick and dirty or they find someone who will on the next project. The shops that promote themselves in this way set the bar for what the expectations are in the field. Repeat.

I agree. I've written bad code but I've seen other folks do much worse, like check in code that was never even run once (could not run properly, regardless of input). Ugh.

Besides, how does one even objectively measure the "badness" of code?

There are plenty successful products out there that have really dreadful code in them - they sort of look OK from the outside but the internals can be pretty damn awful.

So is having a good code base a big factor in the success of a product? Clearly not, from what I've seen.

There are probably a lot more unsuccessful products out there that have really dreadful code. Is it possible to have a good product and have bad code? Of course. Is your product going to die a horrible death because it has a few bad lines of code in it? Absolutely not.

But you're kidding yourself if you don't think that the quality of your code doesn't have an impact on the quality of your product. Well-factored and modular code allows you to iterate much faster in the long term. Of course, if you need to iterate faster in the short term, then by all means use a few well-placed hacks. But you can't let them pile up otherwise you're hurting yourself.

It's hard for me to take something seriously when it openly uses the fallacies like appeal to authority.

And I found his defense of Atwood's comment to be inadequate.

I upvoted this mainly because of reason 7. The joy of side projects particularly contrasted with feature lists in the day job really struck home, having just recently finally launched a side project (http://lessonslearnedby.us/) with a friend, one made possible by being written in a dynamic language no less.

The point about writing the minimum to make something useful is something I've only recently fully grokked and I think the humility of saying "mistakenly believes he's better" is good to keep in mind.

So, Jeff Atwood comes before Jesus and Ghandi?

Ghandi and Jesus know nothing about delivering a product. When they have their own successful startups, then their opinions can count. :-)

I don't see a contradiction between beautiful code and a beautiful product. A great example of this is Apple's SDK. It's gorgeous on the inside and it leads to great products. Inner ugliness is hard to hide. Several examples come to mind.

One of my favorite articles on HN thus far.

I have struggled with a few of these notions myself. It's nice to see another humble perspective.