What kind of code lets a child invent multiplication on their own — and why don't we build everything that way?

TITLE: The Difficulty Was Never the Math

Bret Victor is sitting in front of a screen split in two: code on one side, a drawn scene on the other, sky, mountains, a single tree with branches reaching up. He points his cursor at a number buried in the code, the one that sets how long the branches grow. He holds down a key and drags. The branches lengthen and shrink in the picture as his hand moves, no pause, no rebuild, no gap between the number changing and the tree changing. He didn't write a line, run it, and check the result. He watched the tree grow under his hand.

That's the opening of "Inventing on Principle," a talk Victor gave in 2012 at CUSEC, a software engineering conference in Canada. The talk has since directly inspired products, companies, and academic papers built around its central claim. The claim is easy to state and hard to live by: "Creators need an immediate connection to what they create." Most code isn't written this way. Most code is written the way Victor described the ordinary alternative: type a line, imagine in your head what it will do, compile, run, look, go back, edit again. Every loop of that cycle is a small bet. The bet is that memory can stand in for something you should just be able to see. "If there is any delay in that feedback loop between thinking of something and seeing it and building on it," he said, "then there is this whole world of ideas which will never be."

He didn't mean this as a complaint about tools. He meant it as a description of which ideas get to exist and which ones die in the gap. An idea, in his telling, "starts small and weak." It needs "an environment where the creator can nurture it" while it's still fragile. That's why the branch length needed to be turned like a dial, not typed and recompiled. The right number could then be found by feel, not by guessing.

Then comes the example that gives the principle its sharpest edge: multiplication. "Have you ever tried multiplying roman numerals?" Victor asked. "It's incredibly, ridiculously difficult... There was nothing difficult about the concept of multiplication, the problem was that numbers, at the time, had a bad user interface." Multiplication itself never changed. The representation did. Once digits carried meaning by where they sat instead of which symbol they were, the same mental work that had been an ordeal became something an ordinary mind could pick up and turn over for itself. The math was never the obstacle. The notation was. "Our representations of a system are how we understand it," Victor said. "To understand or build new complex systems, we need powerful new representations."

That's the literal answer to what kind of code lets a child invent multiplication alone: code, or any representation, where the operation is visible enough and the feedback fast enough. Trying something and watching what happens becomes the act of learning it. A child doesn't need the rule explained if she can watch a pattern arrive under her own hands. What she needs is a system built to show her the arrival.

There's a deeper claim here, the one that turns this from an interface lecture into something heavier. It's about what happens to a person who masters a flawed representation. "The most dangerous thought you can have as a creative person," Victor said, "is to think you know what you're doing." Fluency inside a bad system doesn't reveal the flaw. It hides it, because fluency feels like understanding. Whoever spent years getting fast at roman numeral arithmetic had every reason to believe the difficulty belonged to the math. The difficulty was the very thing they'd spent years conquering. Expertise inside a broken interface is the strongest argument for keeping it broken.

That's the part worth naming honestly rather than skipping past. There are layers to knowing something: that it exists, that you understand it conceptually, and that you've lived inside it long enough to feel its shape without reasoning your way there. Only the third layer produces invention. The third layer only comes from immediate, repeated contact. The dial, not the compile cycle. Most software, most processes, most organizations are built to be merely understood, which caps them at the second layer permanently. Nobody discovers something new inside a system they can only reason about from outside it. They discover things inside systems they can reach into.

Victor framed his own commitment to this less like a product roadmap and more like a wound. "When a principle is violated, it hurts," he said. "You see a tragedy... you feel a responsibility to uphold a principle." Most teams never build this way. The world keeps handing people a skill or a job title and asking them to optimize inside it. But the real lever is deciding what you refuse to call normal. "Things don't change the world," Victor said. "People change the world by using things. The focus must be on the using, not the thing." Alan Kay, inventing object-oriented programming, wasn't solving a technical problem. He was placing a civilizational bet: that better representations could "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." That's the scale the question actually lives at. Not "is this tool easier to use." But "what becomes thinkable, and for whom, depending on how close we let someone stand to the thing they're building."

The honest reason we don't build everything this way: the standard is expensive to hold, and the cost is invisible to the people fluent enough to stop seeing it. Every system worth building deserves Victor's test applied to it directly: not "does this work," but "can someone discover something true about it just by reaching in and turning the dial." If the answer is no, the difficulty was never in the idea. It was sitting in the interface, between the idea and the hand that wanted to hold it.