Blog post

posts.yaml

@@ -1,3 +1,6 @@
+- file: posts/the-spiderman-principle.md
+  title: The Spiderman Principle
+  time: 2017-07-05T03:00:00Z
 - file: posts/naive-overview-exercise.md
   title: A Very Naive Overview of Exercise (Part 3)
   time: 2017-06-15T15:00:00Z

posts/the-spiderman-principle.md

@@ -0,0 +1,102 @@
+#### *With great power comes great responsibility*
+
+I was
+[recently reminded](https://twitter.com/snoyberg/status/880637139574304769)
+of a bit of a mantra that I had at LambdaConf this year in
+discussions, and I decided to share it here. I received a bunch of
+questions like these (I'd share the originals, but I have a terrible
+memory):
+
+* Why is there no tutorial for doing X?
+* Why doesn't a library like Y exist?
+* Why has no one created a mailing list/discussion forum/etc for topic
+  Z?
+
+The answer to all of these is the same: __because you haven't done
+it!__ And I don't mean that in the plural "you" or figuratively. The
+one and only reason why things don't get done is because you,
+personally, individually, have not done them.
+
+This of course isn't literally true. There's a possibility that
+someone else will step up to the plate first. And there are limited
+numbers of hours in the day, and no one person can accomplish
+everything. But this mindset is, in my opinion, the only correct one
+to adopt if you want things to happen. It's your responsibility to do
+it; don't wait for others to do it.
+
+You may have some legitimate objections to this philosophy:
+
+* *How can I write a tutorial, I don't understand how to accomplish
+  this?*
+
+    * Go ahead and write it as best you can, and ask people to review
+      it. People are usually quite happy to provide corrections and
+      advice.
+    * A streamlined way of doing this is to send a pull request to an
+      existing repo holding documentation (e.g.,
+      [haskell-lang](https://github.com/haskell-lang/haskell-lang#contributing-content)).
+    * Worst case scenario: ask questions. Encourage people to write up
+      answers. Volunteer to compose the answers into a coherent
+      document at the end. Even people not willing to participate in
+      writing a full tutorial themselves may be quite happy to answer
+      direct questions, especially knowing their work will be
+      preserved for others.
+
+* *How can I write such a library, it's beyond my capabilities?*
+
+    * You'd be surprised about that. Give it a shot. Worst case
+      scenario: it'll be a learning experience and otherwise an epic
+      failure. Best case scenario: you succeed. Either way, it's a
+      win-win situation.
+    * Maybe your desired functionality fits into an existing
+      library. Library authors tend to be quite happy to review and
+      accept pull requests, and contributing an extra function can be
+      less intimidating than writing a new library. (But please
+      consider
+      [opening an issue first](/blog/2017/06/how-to-send-me-a-pull-request?preview=true).)
+    * And if you're certain you're not up to the task: try to
+      encourage others. You may not succeed. But try to make the case
+      for why this project is useful, interesting, necessary, or
+      whatever other adjectives you believe apply. Motivate people.
+
+* *I'm not a community leader, how can I encourage discussions?*
+
+    * There's no such thing as an "official" community leader. There
+      are people with moderator access on some forums or control over
+      certain websites. But that's not what makes someone a leader. If
+      people want to hear what you have to say and join the
+      conversation, you're leading a conversation.
+    * Besides, you don't need to be a leader to start a discussion.
+    * A slight retraction to all of this: if a topic has already been
+      beaten to death, it's almost certainly not worth rehashing
+      it. Reraising controversial points constantly doesn't help
+      anyone.
+
+* *It doesn't seem like the community agrees on this point, how can I advocate it?*
+
+    * Just because many people seem to be advocating X does not mean
+      that it is universally held. There are many reasons why X seems
+      to be the dominant viewpoint:
+
+        * People may be legitimately unaware of alternatives
+        * The people who disagree with X all think it's not worth
+          speaking against the "dominant" opinion
+        * The people who believe X are simply more passionate about it
+          than those that don't.
+
+    * So what if people disagree? Having healthy technical debate is a
+      _good thing_. There are at least three outcomes I can see from
+      such a debate:
+
+        * You realize you were wrong
+        * People disagreeing with you realize they were wrong
+        * Both sides continue with their beliefs, but have a deeper
+          understanding of both their positions and the alternatives
+
+    * But again, try to avoid beating a topic to death
+
+I don't know if people outside the Haskell world experience this as
+much as we do. But I've certainly seen a strong sentiment of "not
+being worthy" or some other such idea. It's rubbish. Join the
+conversation, lead the way, make things happen. The world will be
+better for it.