> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.
Hmm. I’m not one of these tech-stack-driven types of developers they’re talking about in this paragraph, but even I had to raise an eyebrow here — this seems like the kind of rule that’d have a super high false negative rate. I understand the kind of person they’re trying to avoid hiring by accident, but… being excited about a cool language being a “point against” to try to serve that goal? Seems a little over the top
Some nuggets of wisdom from the article when managing an engineering org:
- “if the only reason an engineer wants to work for you is because of your tech stack, that may be a warning sign. Culture Amp therefore avoids hiring engineers who are purely technology-focused. As a product company, we seek to hire people who are mostly excited about our product and its mission, and who are happy to learn new things when necessary to progress that. When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.”
- “Perhaps the greatest challenge for engineers as they reach more senior levels in their career is to make decisions that balance the moment-to-moment joy (or frustration) that a given tool affords them, and the costs (or benefits) that same tool might create for their team, company or client over time and at scale”
> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team.
This is the problem right there. Design system teams never work well. A design system that’s complicated enough to need a dedicated team always creates more friction than it’s worth. Turns out that it’s really hard to standardize UI components in a way that makes them flexible enough to be used across different teams.
The only design systems I’ve seen work well are the minimal ones that just define the color values of the visual theme and look of some basic components like buttons but leave the implementation up to the individual devs.
The problems were not with Elm per se but rather maintaining both Elm and React components.
> It seemed we were faced with a choice: Elm or React. Continuing to support both was fast becoming unsustainable for us.
> The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React.
I remember looking closely at Elm in 2016. I was a year or two into being the first and only web-focused software engineer at a hardware startup. Working solo, moving fast, refactoring aggressively as we iterated and sought our product’s UI, I was craving more help from my language than JavaScript and React alone could offer.
Elm was appealing for all of the reasons described in this post. Functional programming, static typing, batteries included so there would be fewer dependencies to juggle. Improve predictability of my code, cut down on bugs, make it harder to screw up, easier to refactor. People using it seemed to love it!
But TypeScript’s promise was too good. The JS I already knew but stronger! Keep my existing React code base but refactor it to be safer! No need to learn entirely new syntax; instead, adapt my ways of working to let the compiler be a better collaborator! Easy to break out of it when I absolutely had to!
Elm offered many of the same things but require more faith. You invest in different syntax and the Elm way of doing things and you get more safety, better syntax. But the risk of being stuck on a path that’s hard to get off, the cost of ramping up, the challenge of onboarding anyone in the future — that was not in my budget. Even if it was, even if it offered much of TypeScript’s value but did those things better… Was it going to be so much better than it justified the risk? I didn’t see how it could be.
I went TypeScript immediately after the 2.0 release so I could use @types packages from definitely-typed. I spent a week refactoring the entire project and never looked back. It was one of the best investments in technology that I ever made.
I remember a ton of advocacy for Elm on forums and blogs until then. I’m far from an Elm insider so this is pure speculation but if I had to guess, I’d bet wasn’t the only person who doing napkin math about the right frontend language/tooling investment right around that time. I wonder to what degree the rise of TypeScript clipped Elm’s wings and whether a different timeline, maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.
Kevin did the right thing.
IMO these days you have to have very strong justification to use anything other than the top 2 or maybe 3 “mainstream” technologies in any field.
Unless you’re doing something extraordinary (and you’re probably not), most software can be built with VueJS/React TypeScript C# Python Postgres MySQL/MS SQL.
That’s your entire stack covered there.
These technologies get the job done, people know them, there’s massive community support and critically important when you’re hiring, you’re fishing in the big pool.
Also, ChatGPT knows these technologies well and that’s increasingly important.
Any other technology choices really need very strong justification.
And, if your company is still using some branch of the technology tree which several years ago looked like it might have something to offer but has since become obscure or withered in its popularity, it might be time to do as Kevin Yank did and prune that branch off your tech tree.
I really felt this story as someone how had to abandon coffeescript like 8 years ago in a similar fashion.
The syntax was easy, simple, and enoyiable. But at the end of the day, when you implement something like react or angular in real projects can get messy really fast.
At least a lot of the good things of coffeescript still kinda live in TS and new versions of vainilla JS.
I have used elm for a smallish (10 people or so?) team writing software for revenue, and regretted it. that was 4-5 years ago. my reasons had a lot to do with the community around elm, which other comments allude to. This group had different concerns to mine:
The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React.
By that time, TypeScript had grown to be capable enough (and developer-friendly enough) to balance much of what sold us on Elm originally: a usable type system, good-enough error messages, etc. React had baked in some more useful state management primitives that roughly matched Elm’s “batteries included” state management.
I feel much happier writing functional code than OOP code...
And I don't believe much in engineers believing in the company's mission. That is an HR delusion, in my opinion. Yes, of course, some buy-in is good, even ideal, especially later on. But really. At some point, you want a job, you want to get paid, you want it to be somewhat meaningful, but how many choices do you have? I don't have a lot of choices of companies that want me, so I don't much care about the topics I work on. Unfortunately companies care a lot about what they think I want to work on, and they deduce it from facts in my CV I am legally obliged to disclose.
Man, it's 2023 and Elm is still the best thing to use for one-man SPA apps. Unfortunately, the author is right and it's Elm-or-nothing most of the time, no real coexistence of Elm components with TS/JS ones. That adds to the state of Elm being essentially abandoned by its creator.
I'll keep using Elm for now for my one-man UIs, the language doesn't feel old but rather "done". I'm still productive as hell with it, TypeScript will never match. But I'll also never recommend building their startup with it and won't force it to anyone anymore.
> I tell myself that it would be rude and ungrateful to the Elm community for me to publicly declare Culture Amp’s departure from the fold
> What We Owe to Elm
Everyone who talks about Elm sounds like they have Stockholm syndrome. Don't think I've seen a single good experience lately.
I still take the overall point that Elm was simpler, but it’s funny how people react to curly brackets.
When I look at the provided screenshots comparing Elm to JavaScript, I see no meaningful difference in terms of visual noise. Maybe I’ve just spent too much time with too many languages.
I can't be the only person who wondered why a company was still using the Elm email client.
Edit to add: There are enough names and acronyms available. To avoid even temporary confusion, and to make literature searches easier, try to avoid popular ones from yesteryear that were used in your general discipline.
I wish I had, just once, had as thoughtful and thorough manager as Mr Yank (terrible name for an Aussie) seems to be (at least as far as you can ever tell from the self-presentation of an article).
TL;DR: they bridged Elm with React, and when they started using Web Components there was an impedance mismatch between the bridges between Elm/React and WebComponents and the bridge between Elm and React, so they had to pick one of Elm and React.
The title is misleading, they haven't retired anything and won't for a long time.
> Codebases written in contained tech stacks can continue to exist and have features added to them
Phasing out might be a better term.
I always felt the lack of an ABI would hurt Elm, even though I understand the reasons for it.
If you are "ML curious" then I think that Fable / F# is currently the strongest option for compile to JS languages. It definitely benefits from being a mature backend language already.
I must admit, I read this headline and wondered why I should care which email editor they used. I read half the article and still don’t know what Elm is but I’m guessing it’s a language?
At the moment I have a bit of an opposite problem from the "don't hire for passion only": I can't find a new job because I can't hide my passion and experience in Python well enough and somehow Python is regarded as very unprofessional in Germany, so not many companies want to use Python for Full Stack development at all.
don’t hire people if they’re too excited about the tech stack, proceeds to rewrite their app every time a new shiny comes out.
The first time I heard about Elm, I was overjoyed with its promise. For the first time, it made me interested in working on a web FE. To bad it ended the way it did.
Thank you for sharing the article. It makes good points, particularly on the historic context as well as the steam behind Elm waning.
I feel the article is talking about why they fix a strategy mistake by senior engineering leadership.
I guess money was easy enough to get in the last two years so company can afford this kind of expensive experiments..
Off topic: I always really liked https://cultureamp.com web site design.
It uses Tailwind, though appears to be highly customized.
TIL there is a language called Elm. I had thought from the title they had changed mail clients.
Despite the article I now want to learn more about the language Elm.
Evan will be giving a talk about "Elm on the Backend" later this month.
[1] https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend
The video will not be published online.
> NOTE: My goal is to get some early feedback from the in-person audience, so the video will be held back for now. I am not announcing a release, and the roadmap and this status update are still the primary documents for long-time Elm users to set expectations about this work.
[2] https://github.com/elm/compiler/blob/master/roadmap.md
[3] https://discourse.elm-lang.org/t/status-update-3-nov-2021/78...
EDIT:
In the second link, Evan says the following:
> As I allude to in the roadmap 410, nearly ten years of working in constant interaction with “silicon valley mindset” had taken a toll on me in many ways. Within the dominant value system, there are specific rewards and punishments for specific behaviors, and despite my personal views on this value system, I had internalized certain patters of thought and behavior by interacting with it online.
I think sometimes HN gets excited about technology and forgets that tech is made by humans.
Just a reminder to be kind :)
What ever u say, he's a very good writer.
I often have to make these practical considerations too.
I was going to be impressed that anyone was still using Elm. But this turns out NOT to be the E-mail client.
[dead]
[flagged]
Is anyone else disappointed this wasn't about old school email clients, and a belated migration to, perhaps, pine?
I'm not surprised Elm is not viable anymore at a medium or large company, despite continuing to use it every day myself for side projects. The creator has deliberately shunned publicity or popularity for it in the last few years so adoption and therefore hiring has slowed to a crawl. We still have a vibrant and passionate small community, but the emphasis is on "small". No matter how superior it is to e.g. React it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it.
I'm mainly sad that we'll be losing the chance of any future Kevin Yank videos about Elm. I really love the videos of his I've seen on youtube, including non-Elm ones such as the one about how to use VoiceOver for devs [0].
[0] https://www.youtube.com/watch?v=38qQzmkXGS4