It's Hard to Sell a Mental Model
Michael Arnaldi, the author of EffectTS, just replied to me on Twitter:
I’ve built Effect because I had to build a bank with 5 juniors, it ended up working and I open sourced it.
If we understand “juniors” the same way, then I have no doubt it worked.
The story might have been different if Michael had 5 seniors, because EffectTS might make the code safer and more robust, but it makes it less idiomatic, less familiar, and arguably harder to write, because Copilot Chat won’t print it for you.
I like EffectTS a lot, and I hope it has a ton of success. However, I fear that its road to a wider adoption is going to be long and rocky.
It boils down to two things:
- There’s a difference between seniority and “immersion”.
- Explicit error handling might not be the fit for most commercial software.
Seniority vs Immersion
Terms “junior”, “senior”, and “staff” describe the number of years of experience, and the position in the organization.
If they’re correlated to eagerness to learn, idealism, and ambition to write good code, I would guess they’re correlated inversely. People with kids, retirement savings, and a backache, will surely have less curiosity about how that new framework hotness changes the world. That’s totally fine.
Compare this to a young person, their hands just imbued with the power of creation, their eyes bright with infinite possibility. A developer before their first burnout.
I remember my friend Kuba on his first tech meetups after he learnt how to code. You couldn’t have found a person more excited about monads, AWS and differences between frontend frameworks at the same time.
The seniority levels don’t describe how immersed in the craft of programming the person is. Here’s an orthogonal division based on how interested, how immersed the developer is in the implementation intricacies of the software.
- Rowdy Ronin, devs without master, rawdogging jQuery and PHP to hit the market as fast as possible.
- Software Samurai, salarymen, who focus on building great software for their employer. They take pride in their work, but the work is more the code.
- Opensource Oni, demons of GitHub, exploring the uncharted lands of computation. Chronically online, often involved in some argument on Twitter.
It’s tremendously hard to sell a framework that requires a new mental model to the first two groups, unless the benefits outweigh the cost by an order of magnitude.
Especially if it’s not a UI framework.
Frontier and Backwater
For a long time, frontend was the place for experiments, rewriting and trying out new things, and you get an occasion to do this when designers do redesigns and rebrandings. At the same time, the backend was the place of established best practices, old knowledge, and battle-tested solutions. A lot of newly written TypeScript backend code looks similar to the Java code snippets from the books published in the late 90s.
It’s entirely justified, as backend engineers should most often be more concerned with how they orchestrate, operate, and observe their system than the code they write.
Okay, but what if exceptions were actually a better fit for the modern day industry than explicit error modeling?