4 ms·

I'd much rather see code that might take an extra second or two to recognize than code that will need to be completely rewritten X times, constantly maintained,

by Rust 16y ago

I'd much rather see code that might take an extra second or two to recognize than code that will need to be completely rewritten X times, constantly maintained, or is otherwise "stupid" (a technical term I use sometimes). The example code is exactly the type of thing that would raise my hackles - only a really, really bad developer would write that. It's not only easier to write it correctly, but faster.

thetrumanshow 16y ago
"only a really, really bad developer would write that" Let me challenge that and modify it just a bit, and we'll be in agreement: "only a really, really bad developer would write that and actually think that it was a good, elegant implementation." Set aside this specific case, and we can look at the more general state of things... See, there are other contexts where there are different priorities. I have worked in environments where a large if-block was preferred to an elegant solution. This typically happens if you are extending a big enterprise app, have lots of junior developers on a team, or expecting to hand code off to a developer of questionable skills. Thus the business, and everyone in the decision tree, would be happy with the former implementation. If you happen to get TOO fancy, you might even get tagged as someone who writes unmaintainable, obfuscated code that only you can understand. Seen it! Gotta love politics in the office, eh? I've also worked in an environment where there was social pressure to write really slick code. It probably wasn't the same level of pressure that startups seem to apply to themselves, but you could be sure to raise eyebrows (and heckles) in code reviews if you used something like the former 'cute' example. Architectural controls reigned those in, and people learned quickly. In the end, I would say that you can't look at one friggin' function definition and proclaim someone to be a 'bad developer'. Maybe they built the conditional logic from the wording in a functional spec on a late Friday afternoon when they were zoned out and they intended to refactor the code later.
- Rust 16y ago
  I agree with your modification. I haven't had the pleasure of experiencing an environment where a large, hard-coded IF block (or whatever) was preferred to a more stable, maintainable solution, so I can't comment on that. But one of my clients has a brand new codebase written by an "expert" contractor that has all but killed the business. I call it "startup fail" and it's sad to see that stuff happen. Especially when I saw it coming and warned the owner not to hire this particular guy. I suppose it's made me a little knee-jerky when I see code that he would almost certainly have written and been proud of.

by Rust 16y ago

thetrumanshow 16y ago

"only a really, really bad developer would write that" Let me challenge that and modify it just a bit, and we'll be in agreement: "only a really, really bad developer would write that and actually think that it was a good, elegant implementation." Set aside this specific case, and we can look at the more general state of things... See, there are other contexts where there are different priorities. I have worked in environments where a large if-block was preferred to an elegant solution. This typically happens if you are extending a big enterprise app, have lots of junior developers on a team, or expecting to hand code off to a developer of questionable skills. Thus the business, and everyone in the decision tree, would be happy with the former implementation. If you happen to get TOO fancy, you might even get tagged as someone who writes unmaintainable, obfuscated code that only you can understand. Seen it! Gotta love politics in the office, eh? I've also worked in an environment where there was social pressure to write really slick code. It probably wasn't the same level of pressure that startups seem to apply to themselves, but you could be sure to raise eyebrows (and heckles) in code reviews if you used something like the former 'cute' example. Architectural controls reigned those in, and people learned quickly. In the end, I would say that you can't look at one friggin' function definition and proclaim someone to be a 'bad developer'. Maybe they built the conditional logic from the wording in a functional spec on a late Friday afternoon when they were zoned out and they intended to refactor the code later.

Rust 16y ago
I agree with your modification. I haven't had the pleasure of experiencing an environment where a large, hard-coded IF block (or whatever) was preferred to a more stable, maintainable solution, so I can't comment on that. But one of my clients has a brand new codebase written by an "expert" contractor that has all but killed the business. I call it "startup fail" and it's sad to see that stuff happen. Especially when I saw it coming and warned the owner not to hire this particular guy. I suppose it's made me a little knee-jerky when I see code that he would almost certainly have written and been proud of.