[bitcrusher]

No, this is just a fancy tautological development argument. This is how we got into the Java trap (yes, it's a trap) to begin with. Everyone knows Java, you can hire Java devs easily, etc. etc. There's really no reason for this other than: "We don't want to let people grow beyond the cogs we hired them to be". That may or may not be "good" but at least call it what it is: Broken internal human factors processes, instead of couching it in pseudo-technical tomfoolery.

There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.

[carlmr]

>There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.

Put in another way. If your devs can't learn a new language that's not super foreign in 3-4 weeks to a decently productive level, you didn't hire good devs in the first place. I'm sure they would create a similar dumpster fire in Java.

[aloukissas]

True. But it's a big paradigm shift from OOP to FP with pattern matching and adopting the "let it crash" approach. But switching from Java to Elixir is a proven 1000% increase in developer happiness :)

[tracker1]

I've generally had the opinion of a let it all burn first approach... in web ui, first thing I do is mount an error handler for the window and unhandled promises that effectively clears body and set's its' innerHTML to <h1>Unexpected Error</h1>. Similar elsewhere forcing the process to exit.

If you're expecting a certain error condition, handle it, otherwise blow up the world, because you can no longer trust it.

[tracker1]

> There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.

I've had the same problem trying to convey that we don't need someone who is proficient in C# AND JavaScript, and we should be concentrating on the skill that's harder to find good people with experience in, or just polyglots. I'd rather see someone good in 2+ languages that aren't what we're using than one who is bad in those we are.

[KaiserPro]

to quote my argument:

> All of the following is process, business and design failures

none of this is really about tech, its about process.

Your point:

> We don't want to let people grow beyond the cogs we hired them to be

No, The business wants the product to be built as quickly and cheaply as possibly. That is literally what you are paid for. When you hire a cleaner, you don't want them to spend all their time mixing their own blend of cleaning spray, because they read on a blog that its 15% more efficient. You want them to clean.

The very reason that this team were allowed to repeatedly make stupid decisions was because it was dressed up as personal growth. "I'm going to let my team do what whatever they like in what ever tools they like so long as they don't leave, and they hit these moveable targets. Those targets affect my bonus, so lets not make them too hard." Cue a mountain of tech debt, neatly partitioned by age and fashion.

What is so shameful about using the tech you have to finish the task at hand, reusing stuff where you can, so you can spend time on other things? To reference the grain silo analogy again if they all used the same connectors, material, it'd be build by now and could work on designing a better one.

this point:

> There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.

Yes if they are given the correct time and support. When you have to learn, elixir, scala and nodejs all whilst still supporting production legacy as well, its not a nice environment.

Dumping your legacy on bunch of juniors because you were making services to furnish your CV is unforgivable.