11 ms·
If I may float the counter argument: Sometimes the only way to beat analysis paralysis is to pick something, anything, and then pursue it with religious zeal.
by noonespecial 13y ago
If I may float the counter argument:
Sometimes the only way to beat analysis paralysis is to pick something, anything, and then pursue it with religious zeal. (Sometimes even to the point of excluding something you find out later would have been a much better choice)
I can definitely get behind the idea that you shouldn't be an unpleasant bigot about it, but a little dedication doesn't hurt. Its better than "Gandalfing" the merits of this or that technology for longer than it takes to just pick something and get it done.
- StavrosK 13y ago> Sometimes the only way to beat analysis paralysis is to pick something, anything Sure. > and then pursue it with religious zeal. This does not follow. You can pick something while still being fully aware that you just picked it "because you had to", rather than delude yourself into thinking you picked it because it was the absolute best.
- noonespecial 13y agoI'd rather use the perl project of the guy who loves perl than the project of the guy who chose it "because he had to". Not sure if I'd want him as a coworker though...
- StavrosK 13y agoI'm confused. Your original comment discusses a way to beat analysis paralysis, and now you're talking about someone who loves Perl. Is your original comment about a project that needs to get done, and about a way to get it done, or is it about a side-project that one starts just because they love writing it? It doesn't seem like these two are very similar.
- watwut 13y agoWhy? It is quite possible that "because he had to" guy will produce more readable code. There is no reason to care about developers personal relationship with whatever technology. Important question is whether he is able to produce functional, readable, well-designed code in acceptable speed. In case of projects under time pressure, the important question is whether the developer can do reasonable trade-offs between those expectations (eg. sacrifice the right one).
- lostcolony 13y agoAgreed. I want the person who hates the language; they're not going to write their code with all the 'neat' things Perl has, so it comes out looking like someone banged their head against the keyboard a few times, or as poetry (Black Perl). They may not write idiomatic Perl (if such a thing exists), but I bet I can follow it.
- mattfenwick 13y agoI do not believe that "delud[ing] yourself into thinking you picked it because it was the absolute best" is the correct interpretation of @noonespecial's comments. I read @noonespecial's comment as saying that once you pick something, sometimes you should stick with it "even to the point of excluding something you find out later would have been a much better choice". I think the "with religious zeal" bit was either a mistake or was intended to mean something different.
- StavrosK 13y agoMaybe, but I still don't see why that's good. If you find something better later on, and it's so much better than it's worth going through the pain of switching, why stick with the old thing?
- mattfenwick 13y agoI don't see where @noonespecial is claiming that "If you find something better later on, and it's so much better tha[t] it's worth going through the pain of switching", you shouldn't switch. Rather, I interpret it as recognizing both the costs and benefits of switching, as well as the costs and benefits of evaluating costs and benefits.
- StavrosK 13y agoBut then the point becomes trivial. He does say "(Sometimes even to the point of excluding something you find out later would have been a much better choice)".
- tokenrove 13y agoIndeed, and it's also better than being stuck in the hard-scrabble frontier of perpetual novelty, where you spend more time adjusting to your new tools than getting things done. I've come to see moderate (though not religious) hysteresis in technology choice as a virtue.