← back

It's Hard to Sell a Mental Model

3 min read ·

Epistemic Status: Written on an airplane. Should have been a DM, but I’m too stubborn to pay for Twitter Blue.

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:

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.

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?

I wrote some thoughts in defense of exceptions.