4 ms·

"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'

by j_baker 17y ago

"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.

arethuza 17y ago
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.
- j_baker 17y ago
  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.
strebler 17y ago
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?
tomlin 17y ago
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.
deleted 17y ago
[deleted]

by j_baker 17y ago

arethuza 17y ago

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.

j_baker 17y ago
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.

strebler 17y ago

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?

tomlin 17y ago

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.

deleted 17y ago

[deleted]