Background: I’m a backend engineer in a company in China and we use Ruby mostly for our API services. We have about 7 Ruby engineers and several backend engineers who are familiar with Go, Java, Python.
I love Elixir and want to promote it here. But the biggest problem is that it’s really hard to hire Elixir engineers later on(especially in China), which is bad for a company. And it’s hard to change the situation by myself. What I can do now may be teaching others Elixir(?). I prefer giving a series of talks about Elixir instead of just pasting some links. I don’t think anyone will care if I tell them to learn Elixir instead of teaching them by myself.
Any idea for the content of the talks? Any suggestion to promote Elixir in my(or other) company?
I think there’s nothing better than being able to solve the problems Ruby can’t solve (easily). If you od have use case where Ruby will struggle - and Elixir won’t - push for trying Elixir in that context. It can be part of API ,something simple. If you are able to show real engineering value - others will become interesed.
It will take your average Rails developer a matter of weeks to learn Phoenix and Elixir. I wouldn’t worry about hiring if you can hire Ruby devs and work with them for a few weeks to get them up to speed.
Give my example: I’m stupid new Elixir developer that already have some Elixir jobs and sometimes I can put my own 2 cants on other Elixir projects (for example I found some bugs in floki). How many Ruby beginners you know like me or how many Ruby developer you know that talked with Ruby God? hahah
I don’t remember that I have so many successes in similar time with Ruby.
Say that José Valim and our forum are always open on new developers . Every time I (and not only me) discussed with him then I don’t feel stupid. Without problem in just few posts I understand why he introduces new things and how he choose this way. Previously I don’t even have so many good answers on so many newbie questions so fast without stackoverflow like marking posts.
And much more … If you are starting to say what’s good in Elixir then easier way is to start talk with question:
What’s bad in Elixir?
that will ends as fast as supervisor will restart crashed process. hahah
Don’t stress and say what you love in it and why you love it - keep it nice as your Elixir code
Play a game! Let’s create a boards with points and count them for Ruby and Elixir. hahah
Also there is a sizable Erlang community in China iirc. Alibaba being a huge users, but not only them. Look around, you should find help from there too.
As other have already pointed out you should pick a first example use case for which elixir/phoenix is a much better solution AND which is relevant and interesting for the company.
While it might take a relatively short time to teach a ruby/rails person to use elixir/phoenix it generally takes a much longer time to teach people what is actually going on inside the system. These are not the same thing. The 2nd one is critical when you are building the systems.
The second one means that in some cases it might actually be better to take experienced erlang people and teach them elixir/phoenix.
Yes, the structure of the systems you build will be very different, or at least they should be different, so mapping a system built in ruby directly to elixir is not always a good idea.
The only way we can create more Elixir engineers is by creating more Elixir jobs. The best way to do this is to get Elixir apps into the wild. The more Elixir apps that need to be maintained, the more elixir jobs will be created, and the end result is a self fulfilling prophecy.
What you mean by an “Elixir engineer”? I am going to be a bit of a wet blanket here and say that IMAO this not the same as someone who writes apps or uses elixir/phoenix to build web-site. It is someone who has a deep understanding of the internals of such systems and so can use Elixir/erlang to build systems.
In the US the term “engineer” is often actually used as a job title rather as a “certified qualification” - in the vein of “sanitation engineer”: [person employed to collect and haul away trash]
(http://www.thesaurus.com/browse/sanitation%20engineer).
So often a “JavaScript Engineer” is simply a JavaScript coder (it’s in that space where I observed that misuse first - but I don’t actually know where it started).
So the term “engineer” has basically become meaningless (unless it is certified and backed by some kind of accredited professional institution) in the software space.
Apparently there is something wrong with just being a software (solution) craftsperson.
Building confidence in the language with the team and company is critical. I’d recommend starting with a small project, to build confidence with the company. Then see about getting your team to help out with small feature/maintenance projects. If you can accomplish this, moving forward with other/larger projects should be fairly easy.
You typically need to convince multiple people & roles if you want to introduce new tech. People have already covered pitching to colleagues and engineers. New shiny is often (and rightly) seen as risky, unproven, hard to debug, changing fast, hard to get relevant skilled staff. What about the rest?
The thing that I see with erlang & elixir that is IMO the key feature is that they are platforms for building robust, reliable systems. This means -:
systems that handle failure tolerantly and gracefully under extreme load or unexpected conditions. - easy to debug live in production without the need to recompile, or introduce complicated extra tools to do so
systems that recover mostly automatically (when appropriate consideration is given during design) and that do not require manual intervention out of hours to keep operating
These are prized features that are core to the BEAM that are very hard, if not impossible, to retro-fit to other systems. I do not think that a couple of months is sufficient for a ruby or java developer to become proficient enough to design this sort of system, but they can easily start shipping modules and non-distributed systems code effectively. This needs to be kept in mind - robust reliable systems require a fundamental practical understanding of real world distributed systems.
In my experience of large systems software the above attributes are killer features both at scale and in production. See how your management feels about these, and you may find introducing OTP is a lot less complicated than you think.
BTW I highly recommend Francesco Cesarini & Steve Vinoski’s book https://www.amazon.de/Designing-Scalability-Erlang-OTP-Fault-Tolerant-ebook/dp/B01FRIM8OK its not lightweight but it is essential reading, and you should be able to find one of Francesco’s recent talks that gives a good overview of this, a great introduction for your more technically minded managers.
No, there is nothing wrong with being a software (solution) craftsperson, we just had a different definition of “engineer”. My understanding of the term is more towards the “certified qualification”.
Depending on your audience and who you’re trying to convince, you might need to change your “pitch”. More business oriented people might not care about terms like “fault-tolerance” etc but they will probably listen when you map that feature (or the lack of it) to the financial impact it might have to the business (i.e “this will save us this much money because…”).
In terms of getting the team on board, something I found effective is building something that the team finds useful (it’s used internally or they have a general interest in). Then you can explain how the project benefits from being written in Elixir. If it’s used internally, you can pair with them on the actual code and let your enthusiasm affect them over time
You don’t have to convince everyone, you just need to convince the right person. At every company, there is a leader or influencer. They may be the CTO or a senior engineer. If you convince them, everyone else will accept it.
At my own company, I promoted Elixir and met strong resistance. The language is different. It’s weird. I don’t understand. Why do we have to use another language? JavaScript is fine. Then one of the architects did take a look and saw the benefits of the OTP. And that is what convinced him. Not Elixir, but all of the awesomeness of the OTP. Now we have several Elixir projects in active development.
