Finding signal on Twitter is more difficult than it used to be. We curate the best tweets on topics like AI, startups, and product development every weekday so you can focus on what matters.
Originally published by @jamwt on X. Tech Twitter preserves the original source alongside this readable edition.
Before you dive in
• Explore the distinction between simple and easy in software design, and how AI's zero learning cost is reshaping technology adoption and backend...
Best for builders who want practical takeaways. 7 min read.
(reposting this Jan 2025 article from my blog, as I'm finding myself referring to it often recently)
Back in the late 1990s, when I was first starting my software career as an intern, I worked with a senior engineer named Stan. I admired the hell out of Stan. Stan just knew stuff, and he was passionate about leveling up all the new, junior people flooding into software engineering during the first dotcom boom.
Two specific pieces of his advice ended up having a lasting impact on my career:
Stop using Perl and take a look at Python. (While not the subject of this post, wow, did this make the next decade a lot more fun.)
Quit clicking your mouse around your editor and learn vi.
I wanted to be like Stan, so I ground out the learning curve and got vi fundamentals under my belt. And suddenly, my coding productivity went through the roof. I kept my hands on home row, and even my RSI cleared up.
Soon, I was a full-throated vim advocate. But when I’d try to coax fellow programmers to learn vim, we’d often collide into the “weird” wall together:
Them: “So, how do you delete a line?”
Me: “dd”
Them: “…wtf?”
I mean, it’s hard to argue that “dd” is more intuitive than dragging your mouse over a line and hitting the delete key. Usually, at some point in those first few hours of struggling with “dd”, “cw”, “f(” and the like, the experiment would get abandoned as a hopeless exercise in gobbledygook. I’d retreat to my desk, and they’d retreat to their mousey editor.
My rationalization was that people sometimes think there’s only one curve to consider with a new tool or idea: easy to use. But my suspicion was that there are two distinct curves at play here: (1) easy to use and (2) easy to learn. Some things are harder to learn, but once you have them down, they’re very, very usable day to day. But I just couldn’t put my finger on a succinct way to make this argument.
So when a certain Rich Hickey talk from Strange Loop made the rounds one day in 2011, it was like a lightning bolt to the brain.
Simple Made Easy
We doomscroll, you upskill
Get the 10 tweets shaping how builders think today.
Newsletter
We doomscroll, you upskill
Get the 10 tweets shaping how builders think today.
Rich’s talk Simple Made Easy rendered a very clear distinction between two ideas:
Simple things are about a lack of interleaving. A simple thing is a “true primitive” that can be composed with other systems without that composition changing its behavior. Simple things are objectively simple. You can evaluate them as simple without relying on personal context.
Easy things are nearby. The easy way is the fastest way to accomplish something. And therefore, easiness is relative. It’s an expression of nearness based on where you are, what you already know.
As an example, if I’m a vim user and you’re an Emacs user, deleting a line in vim is easy for me—but perhaps not you. However, deleting a line in both editors is simple.
Revisiting my practical but less rigorous framing:
Easy to use for engineers usually means simpler. This is because professional engineers are (perhaps definitionally) composing things together. So simple primitives give them the most flexibility to build all kinds of things without emergent complexity or constraint.
Easy to learn is easy! The distance from what I already know to fluency with a new tool or idea is small.
From Rich’s talk:
Why composition enables simplicity
The “working set” of ideas humans can consider at the same time together has remained relatively constant in recent history. Our brains are not significantly more capable in this regard than they were 100 years ago. We have a limited “context window” for high fidelity information. And yet we’re engineering more and more sophisticated systems and products over time. How is this possible?
Abstraction makes it possible. Eventually we figure out the right simple, quintessential API to represent a bundle of primitives that everyone used to need to compose manually.
If that quintessential API can provide the utility 99%+ of the time without needing to deconstruct how it works, it becomes a complete abstraction, and that abstraction is itself a new primitive.
But if that API has subtle behaviors that differ depending on what other APIs it's being composed with, the API consumer still has to understand a lot about how it was made: what are the complications, and in what specific circumstances do they occur? This need to understand the interior of the abstraction increases the “working set” of things that have to be understood by a fixed-sized brain!
So the “leaky abstraction” is not simple, and it will eventually fail as too complex.
And ultimately, this is a significant part of why vi is so successful—it’s excellent at composition. Once you learn a few operations like “d”, and movements like “w”, you realize you can just chain them together to do basically anything. You’re not really memorizing all the jumbled clusters of characters, you’re merely memorizing the handful of primitives.
Another great slide from Rich’s talk:
What does this have to do with AI?
So far, AI isn’t significantly better at dealing with complexity than humans are—in other words, it has context window problems. In fact, AI models our way of “thinking” so well, it benefits from simplicity as much or more than humans.
Humans are quite attracted to easy. After all, it requires time and energy to cross the gap to understanding a new abstraction. In order to put in the hard work to get to a new plateau of simple, it’s reasonable for a human to ask:
Will this actually be better?
Will the abstraction end up leaky in practice?
Will others be willing to use this too so there is an ecosystem, employment opportunities, and the culture necessary to work together on this abstraction?
Essentially, is it worth it to learn this vs. my easier alternatives?
However: AI doesn’t care about easy. AI benefits from simple just as humans do, but if you tell it to use something new, it will. It has no need for proof or trust, and it doesn’t value the opportunity cost of its learning time.
Interesting new opportunities…
At @convex, we’ve built something ambitious and much simpler than the status quo ways to build application backends.
The primary complexity we’ve eliminated is:
Reasoning about concurrency
Reasoning about consistency
Reasoning about caching
It turns out those are three of the biggest concepts that trip up both humans and AI when it comes to getting backend code correct in practice. Automatic data management (reactivity) makes it so everything the agent needs to know is in the context window.
But in order to provide that simplicity, we needed to replace that status quo with something new. New APIs for new abstractions, and a new way to work with them that requires a bit of learning. And as developers consider Convex, they pause and ask the usual questions: “Will it actually be better? Will it be worth it to learn?”
AIs do not hesitate! So LLM-powered codegen works very well on Convex.
This opens up an interesting consideration for our product, and I’d imagine for technology products in general:
Will software be able to more rapidly move to higher-level abstractions now because AI values “learning time” at zero?
Can these new abstractions be validated ahead of human adoption by seeing how successful AI is with their designs?
This is triggering a reexamination of the way we think about Convex and how we design future versions of our API. It’s early, but very interesting.
June 2026 update: The theories here feel validated. Convex's early funnel is much stronger because agent-assisted humans no longer need to be willing to “learn” Convex before they see value.
