[romanovcode]

I was working with this guy - he always tried to prove that everything is possible wasting time. He ALWAYS over-complicated simple things. He was horrible to work with and everyone hated him.

Not to say you are just like him etc. but this post reminded me of him because it was probably exactly what he would do.

[kbenson]

Wasting other people's time is a negative, but deepening your understanding of a topic by examining edge cases is generally worthwhile, IMHO.

[Orangeair]

I think the difference really lies in WHEN you do the examining. If you think to yourself, "Hey, that's cool, I'll check it out later," then there's no problem. However, when it gets to the point where you're thinking, "My code must be 110% correct! This is an immediate priority!" then maybe you should be re-evaluating your decision making process.

[jmngomes]

I think he's referring to some people's inability to balance technical issues and product commitments (deadlines).

Focusing solely on the means and disregarding the ends is a good way to not deliver anything useful. Most times, things need to be good enough, not technically perfect...

[diminoten]

> Most times, things need to be good enough, not technically perfect...

This sentence means almost literally nothing, given how varied both "good enough" and "technically perfect" definitions are for each developer.

[spenuke]

Is it really fair to call poor code an edge case? If not for the double-equals typo, which most code reviews would fix, this wouldn't work.

I'm more interested that this team has conversations where person A asks a really simple question that should be able to be tested in 11 seconds, person B gives a patently false answer that mistakes && for ||, which is the very thing person A is asking about. Meanwhile person C goes and spends 11 days looking for a loophole and writing a blog about it.

As a person gearing up for my first web dev position, I really wonder if this is what constitutes professional Javascript development and ask myself if I shouldn't be applying to jobs already.

[kbenson]

No, person C saw an interesting question, and decided to go on an exploratory journey to see what's possible. In any job requiring mental aptitude, you'll find natural curiosity an asset, as long as you keep it within bounds.

To be clear, anyone that's presented a question about a tool they are using that may pertain to it's use (be it efficiency or correctness) that shows zero interest in the answer (whether or not they have time to pursue an answer) is not someone I want to work with or manage, and should probably find another career, because the one they are in isn't holding their interest. Work doesn't have to be the most important thing to you, but if you don't like your job, the people around you WILL notice.

[spenuke]

I'm not sure your second paragraph is clear, to me, at least. Person C admitted that their only contribution to the conversation was to announce that they had been nerd-sniped. Which means that they showed zero interest in the "question they were presented with", because they were sidetracked by another, more interesting (to them) problem.

Meanwhile, person A's question went unanswered. I would consider this a case of not keeping curiosity within bounds. Wouldn't you?

I agree wholeheartedly that curiosity is a great motivator, one that I would want driving all my coworkers. But as this blog presents it, the curiosity suffers from the greatest threat to curiosity, which is a lack of discipline that ensures the curious person never rises above a dilettante. I speak from first hand knowledge here - I've wasted more than my share of time doing something just for fun that benefits nobody.

If it were not the case that Person B, the implicit authority figure in the scenario, gave a totally backwards answer to Person A, OR ( || ) if it were not the case that Person C failed to alleviate the confusion of Persons A and B, then I would not see any problem with going off on a trip down pedantry lane. As it is, the whole organization looks like a gang of clowns. Nobody can answer the most basic of syntax questions, and one person even takes a faulty intuition ("b can be both 80 and 443") and follows it on a Quixotic quest into the arcana of the language spec. It's almost as though he stumbled on the real value of the quest (how evaluations of == and === are actually implemented) by sheer accident, in spite of himself. Luckily, many quests follow this pattern.

For what it's worth, I do find the discussion interesting. But it's interesting in way different than that of edge cases. Deliberately breaking something by using it in a way it was never intended to be used can be enlightening if you want to fend off would-be attackers. It exploits the system's implementation constraints. On the other hand, an edge case highlights the edges of legitimate use which the system was never designed to account for. It exploits the system's lack of comprehensiveness. The distinction is a good one, I think.

For example, consider a chair. An edge case might be a 600-pound man. The engineers didn't take this legitimate use of the chair into account when they determined the thickness of the material. That's an edge case. It's not quite the same as saying that the engineers didn't take into account that wood is flammable. This example is not the best, but I'm now well too far into my own trip down pedantic lane to spend any more time trying to improve it. :)

[philip_roberts]

It's not made clear from my post, because I felt it was entirely irrelevant to the context of the post itself (which was merely intended as an interesting meander through the thought process and experiments my mind went through over time) but I stripped a number of comments from the screencap wherein the question was in fact answered.

Had I suspected the quality of my team, or my discipline would be under question, I would have left them in :)

[nobotty]

how is the operation of "==" an interesting question to anyone but a novice javascript developer? I think this post is going to give me an aneurism.

[hackinthebochs]

It's interesting because it looks at the implementation of '==' vs '===' and how this behavior can be modified at runtime. Every good "hacker" should find this interesting on some level.

[jacalata]

I don't know if the last bit was added later, but he did find a solution which would work without using ==

[e28eta]

I think it's worth pointing out the article writer recognizes this is a distraction. In the comic, nerd sniping causes people to forget they're crossing the street and they wind up being hit by a car, which is a pretty serious distraction from the task at hand.