Don’t Dork It Up: Advice for building web applications

For us it has directly impacted how we approach incorporating feedback into our product. Appropriately responding to user suggestions is arguably the most difficult problem our startup and many others will face. We test and release many experiential features, but we have become harsh critics for keeping features on board. I can’t think of a more impactful lesson so far. Is this not as meaningful as I think?

Every time he learns something is awkward or unattractive, he adds it to his meaning of the word "dork." Then he notices that "dork" is an effective cue for everything he has learned about awkwardness and unattractiveness, and he concludes that everything he has learned is implicit in the shared meaning of the word "dork." Actually it's just part of his meaning of the word, so his use of the word communicates a lot less than he thinks it does.

This phenomenon is responsible for most of the mystical BS surrounding traditional martial arts training, leadership training, any kind of training where people venerate inane or vague pronouncements because of the authority of the teacher. The teacher says cryptic things to you and makes you work your ass off, and eventually (through your hard work) you learn enough to figure out what he means by his vague aphorisms. Or maybe you don't, maybe you conceptualize things entirely differently, but it doesn't matter because his language is so vague you can attribute your meaning to his words.

Seems clear to me that the original advice was, "don't make something that only dorks would like," i.e. don't make it overly complicated. He then took that lesson and applied it to other parts of his business that don't really have anything to do with "dorks" necessarily.

I think the original advice is valuable since it goes against the instincts of most hackers.