From 65b900e73c1875e4fdb136f6e6fd517c9e5922c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Sun, 26 Mar 2017 12:37:17 +0200 Subject: New article: the elephant in the room --- .../articles/the-elephant-in-the-room.asciidoc | 148 +++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 _build/content/articles/the-elephant-in-the-room.asciidoc (limited to '_build') 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. -- cgit v1.2.3