3 ms·

What do you do after the experiment is done? I’ve been through that already for a relatively minor project and been asked not to do it again, even though the p

What do you do after the experiment is done? I’ve been through that already for a relatively minor project and been asked not to do it again, even though the project worked out very well. The problem is we end up with something that can’t be properly maintained if I leave, and even if it’s a small service, it tends to grow in scope. Sadly we don’t really use any of the VMs you listed either. People around me don’t doubt that you can do cool stuff in Elixir or Clojure, they just think it’s too hard to hire for these languages, and that the same is possible in any scripting language with Redis, Kubernetes, Kafka, etc.

didibus 8y ago
> Sadly we don’t really use any of the VMs you listed either That might be too much to ask then. A change in runtime is much more difficult then a change in language. That's also the beauty of hosted languages like Clojure[Script] and Elixir. They give you a painless transition which doesn't need new infrastructure, and you can slowly adopt them for parts of your code. > I’ve been through that already for a relatively minor project and been asked not to do it again, even though the project worked out very well I think it's important to emphasise the benefits. This would have taken me twice as long without X language. X language allowed it to be more robust and suffer from less operational issues. Also the business shouldn't know about the language choice as much as possible. You can say things like, because of our use of the Clojure[Script]/Elixir technology and library, the project was delivered twice as quickly. > they just think it’s too hard to hire for these languages, and that the same is possible in any scripting language with Redis, Kubernetes, Kafka, etc. For this it helps to emphasise ease of learning, and quality of engineers. Something like, any talented engineer can pick it up quickly with minimal overhead. If an engineer can't pick it up, they might have been a bad hire. Engineers interested in such languages are normally more passionate, polyglot, and are continuously learning on their own time. They're most likely better engineer then the average, and this is actually a good way to appeal to such high quality talent and recruit good engineers. So basically, you have to be a good marketer and leader, since you'll need to evangelize and lead people into adopting the new language, starting with a good hand off to the next person needing to maintain the code.
- ramchip 8y ago
  I've done many of these things, documenting the arguments, evangelizing and building up enthusiasm in my team (I didn't write the Elixir system alone), etc. but was still told by our lead engineer and technical managers not to use the language for new systems. Some arguments I heard: * Even if we can find some people excited about a minor language right now, what about in 10 years? The language could be abandoned and nobody would want to learn it. If we use a popular language instead, we know we'll be able to maintain the systems and hire people for a decade or more. * It's already hard enough to hire average engineers fresh out of school, let alone experienced, polyglot ones. * We couldn't reuse internal libraries in popular languages so our systems would take more work, and other teams wouldn't be able to help us. * Kubernetes / Kafka / Redis are language-agnostic and more powerful than OTP supervision / messaging / ETS. IMHO some of these arguments are flawed, but it's been difficult getting the more resistant folks to actually consider the pros and cons and not just toss the idea aside. Your comment about hosted languages is a great point though, and your post makes plenty of sense. Thanks for the motivation :)
  - didibus 8y ago
    Well, it looks like you did try hard then. You definitly get my respect for that. Your company and leadership sounds simply too stubborn. In that case, I think there's only three options. 1) Resolute yourself that you won't be working in your preferred language. And try instead to find satisfaction in other aspects, such as your designs, maybe bring in some functional influences, adopt more data driven patterns, etc. 2) Look for a more open minded place to work. Honestly, that might be a good career move. If all they can hire are new grads or mediocre coders who can't pickup a new language, what's in it for you? Who will you learn from? Remember, 10 years from now, do you want to have 10 times the same experience, or 10 years of experience? If the latter, it means every year you have to be given an opportunity to take on something you don't know, that's at the next level of your capacity. Which allow you to grow, learn new skills and master existing ones. 3) Work to gain trust and leadership yourself, until you are in a position with the right authority to make the decision your own. I think all three are fine choice by the way. With different trade offs of risk/reward/effort. It's a personal choice. I'm just listing them, because sometime we don't realize there are options.

didibus 8y ago

> Sadly we don’t really use any of the VMs you listed either That might be too much to ask then. A change in runtime is much more difficult then a change in language. That's also the beauty of hosted languages like Clojure[Script] and Elixir. They give you a painless transition which doesn't need new infrastructure, and you can slowly adopt them for parts of your code. > I’ve been through that already for a relatively minor project and been asked not to do it again, even though the project worked out very well I think it's important to emphasise the benefits. This would have taken me twice as long without X language. X language allowed it to be more robust and suffer from less operational issues. Also the business shouldn't know about the language choice as much as possible. You can say things like, because of our use of the Clojure[Script]/Elixir technology and library, the project was delivered twice as quickly. > they just think it’s too hard to hire for these languages, and that the same is possible in any scripting language with Redis, Kubernetes, Kafka, etc. For this it helps to emphasise ease of learning, and quality of engineers. Something like, any talented engineer can pick it up quickly with minimal overhead. If an engineer can't pick it up, they might have been a bad hire. Engineers interested in such languages are normally more passionate, polyglot, and are continuously learning on their own time. They're most likely better engineer then the average, and this is actually a good way to appeal to such high quality talent and recruit good engineers. So basically, you have to be a good marketer and leader, since you'll need to evangelize and lead people into adopting the new language, starting with a good hand off to the next person needing to maintain the code.

ramchip 8y ago
I've done many of these things, documenting the arguments, evangelizing and building up enthusiasm in my team (I didn't write the Elixir system alone), etc. but was still told by our lead engineer and technical managers not to use the language for new systems. Some arguments I heard: * Even if we can find some people excited about a minor language right now, what about in 10 years? The language could be abandoned and nobody would want to learn it. If we use a popular language instead, we know we'll be able to maintain the systems and hire people for a decade or more. * It's already hard enough to hire average engineers fresh out of school, let alone experienced, polyglot ones. * We couldn't reuse internal libraries in popular languages so our systems would take more work, and other teams wouldn't be able to help us. * Kubernetes / Kafka / Redis are language-agnostic and more powerful than OTP supervision / messaging / ETS. IMHO some of these arguments are flawed, but it's been difficult getting the more resistant folks to actually consider the pros and cons and not just toss the idea aside. Your comment about hosted languages is a great point though, and your post makes plenty of sense. Thanks for the motivation :)
- didibus 8y ago
  Well, it looks like you did try hard then. You definitly get my respect for that. Your company and leadership sounds simply too stubborn. In that case, I think there's only three options. 1) Resolute yourself that you won't be working in your preferred language. And try instead to find satisfaction in other aspects, such as your designs, maybe bring in some functional influences, adopt more data driven patterns, etc. 2) Look for a more open minded place to work. Honestly, that might be a good career move. If all they can hire are new grads or mediocre coders who can't pickup a new language, what's in it for you? Who will you learn from? Remember, 10 years from now, do you want to have 10 times the same experience, or 10 years of experience? If the latter, it means every year you have to be given an opportunity to take on something you don't know, that's at the next level of your capacity. Which allow you to grow, learn new skills and master existing ones. 3) Work to gain trust and leadership yourself, until you are in a position with the right authority to make the decision your own. I think all three are fine choice by the way. With different trade offs of risk/reward/effort. It's a personal choice. I'm just listing them, because sometime we don't realize there are options.