New article: the elephant in the room

1 files changed, 148 insertions, 0 deletions

diff --git a/_build/content/articles/the-elephant-in-the-room.asciidoc b/_build/content/articles/the-elephant-in-the-room.asciidoc
new file mode 100644
index 00000000..24aa0006
--- /dev/null
+++ b/_build/content/articles/the-elephant-in-the-room.asciidoc
@@ -0,0 +1,148 @@
++++
+date = "2017-03-26T00:00:00+01:00"
+title = "The elephant in the room"
+
++++
+
+Have you ever tried telling someone why they should use
+Erlang? You boast the smaller code size, the auto healing
+mechanisms, the distribution and they seem really excited.
+They wonder why they never heard about Erlang before. And
+then you show them what the code looks like. All excitement
+goes away. The smiles disappear. Their face starts
+becoming really serious.
+
+You lost them. You know you lost them. They comment on the
+syntax, or perhaps you do, already admitting defeat. It's
+unlike anything they have ever used before. And they will
+most likely end up not using it.
+
+What about people who already know what the syntax looks
+like? As soon as you mention Erlang, the topic of the syntax
+comes in. It's like nothing else matters.
+
+Perhaps the topic of syntax didn't come up. But they're
+still not going to try Erlang because of it.
+
+You're probably not having these kinds of interactions at
+Erlang conferences. This doesn't happen with people who are
+already somewhat interested in, or need, the features that
+Erlang provides. With them the syntax is at worst a minor
+inconvenience.
+
+This happens because most developers are familiar with
+syntaxes that look nothing like Erlang. To be clear, I
+include language features and other concepts like objects
+as part of "syntax" here. Familiarity is a very important
+factor to drive adoption.
+
+You can see an example of that in the Elixir world, where
+the majority of people come from Ruby or already knew and
+liked Ruby. The 2016 survey tells us that 59% of Elixir
+developers were using Ruby primarily before. That's in
+large part because of the syntax. They will deny it of
+course and find other reasons. And yet, we don't see such
+a strong adoption of Erlang from Ruby developers, before
+or after Elixir appeared.
+
+Side note: have you ever wondered why the Elixir community
+is, I quote, much friendlier than the Ruby community?
+Despite having much of the same people?
+
+Before we continue, let me be clear. I love the Erlang
+syntax. It is simple and explicit. It is powerful, especially
+when dealing with binary data. It has very few quirks.
+It has little to no ambiguity. It's great. Except for
+persuading people to use it.
+
+Over the years I have been writing Erlang, I have seen
+very few people point out that the syntax slows down
+adoption. We have no problem with it, so why would others?
+At the same time, people coming to Erlang come to solve
+a real problem they're having, so the syntax is fairly
+secondary. Even if they hate it at first, they know they
+can solve their problems despite the syntax.
+
+You don't build a popular product or language by solving
+people's problems though. In general you end up solving
+some problems and creating new problems. No, you build
+a popular product by *convincing people to use it*. And
+you make them stay with your product by making them
+*commit* to using it.
+
+Take MongoDB for example. It didn't become popular by
+working, or even by being practical. It wasn't performing
+its primary function and was losing people's data. That
+didn't stop it from becoming popular. Smart people would
+knowingly use a database that was losing data. Think about
+that for a minute.
+
+MongoDB of course had a huge marketing machine, and they
+focused on that. They helped organize many meetups all
+over the world, complete with various swag items given
+for free, including a small handbook about MongoDB. All
+people had to do was show up.
+
+They didn't go tell people to look at all the weaknesses
+their product had. They focused on the strengths. On
+what would convince people to try it. People would go
+to meetups, discuss with people, commit to try it (or
+try it at meetups directly), and by doing so sell MongoDB
+to themselves.
+
+How do we get people to meetups though? That'd be the
+first step: you need to *catch people's attention*.
+I believe MongoDB did this using benchmark results.
+Ironic isn't it? MongoDB gets fast benchmark results
+because they lose data, and this gets everyone to buy
+into the product.
+
+The key points to remember about this are:
+
+* catch people's attention
+* show your product's strengths
+* make people take a commitment
+
+Once they commit to something, you win. Everyone will not
+end up ultimately using your product of course, but it's
+at the very least become a consideration. It's on their
+mind. Their resolve will be stronger when they ultimately
+try it and inevitably run into issues.
+
+Erlang's syntax is a weakness. Almost nobody looks at the
+Erlang syntax and falls in love with it at first sight.
+No, it takes time to learn it and understand how good it
+is. You need to sell Erlang to people without showing
+the Erlang syntax. If you do show it, then you need to
+hide the parts that feel alien. Function calls are OK.
+Recursion, not so much. Maps are OK. Records, not.
+
+Avoiding code is not always possible when you try
+to sell it, especially to developers. You can however
+prepare them to accept the alien syntax by admitting
+that the syntax is not perfect before you show it.
+You can do this while praising it at the same time.
+For example, "the syntax is a little out there, but
+it matches the concepts perfectly, it will all make
+sense when you start learning".
+
+This might not be the best introduction. Someone will
+need to A/B test it to find the one that gives the
+best results. But that should give you ideas.
+
+When something terrible happens, mentioning that this
+isn't the end of the world *before* you tell others what
+happened will soften their reaction. When someone
+breaks your favorite item and cries over it calling
+themselves stupid, it's harder to get mad at them,
+compared to the same event with no emotional reaction.
+
+Our behavior is largely dependent on what's at the
+top of our mind, so it's up to you to take advantage
+of this to make your case in the best conditions.
+
+Next time you try to make someone use Erlang, remember
+that you should aim for getting a spoken commitment
+out of them, if possible before you show the syntax.
+If that's not possible, then prepare them to accept
+the flaws or the weirdness before they see them.