Categories
Authors Books Business

The Whetstone of the Box

Give a team an unlimited budget and no deadline, and you almost guarantee their project will never ship. We spend our careers fighting for more runway, more resources, and a completely clear calendar, convinced that absolute freedom is the prerequisite for great work. Yet, when the walls finally fall away, we usually just freeze.

David Epstein’s upcoming book, Inside the Box, circles this exact paradox. His premise, arriving in early May, is that constraints do not diminish our capabilities; they forge them. We spend so much of our lives trying to escape boundaries, failing to recognize that those very boundaries are what give our efforts shape.

I think about the early days of writing code. We were working with severe memory limits—kilobytes, not gigabytes. Every line had to justify its existence. There was no room for bloat, no excess capacity to mask sloppy logic. It felt restrictive at the time, like trying to build a ship inside a bottle.

But that unforgiving physical boundary forced a ruthless elegance. You had to understand exactly what you were trying to accomplish. The constraint wasn’t an obstacle to the work; it was the whetstone that sharpened the blade.

We see this everywhere, once we learn to look for it. A photographer framing a shot with a fixed prime lens cannot rely on a zoom ring to find the picture; they have to physically move their feet. The limitation forces engagement with the physical world. Without the walls of a canyon, a river is just a swamp. It is the restriction that creates the momentum.

Epstein’s focus on how constraints make us better feels like a necessary corrective right now. We live in an era of infinite leverage and boundless digital canvases. The friction has been removed from almost everything we do.

But friction is where the traction lives. When we strip away all our limits, we don’t gain wings; we just lose our footing. We need the edges of the box to know exactly where we stand.

Categories
Computers FORTH IBM Programming

The Architecture of the Stack

Back in the early 1980’s when I worked for IBM, I was able to acquire my own IBM PC and experience my own form digital frontierism. Today I really wish I had a logbook at hand with a record of everything I did as my ability to recall those details has faded with age. A couple of those memories that still do remain with me involve two obscure languages: APL and FORTH. And then there was Borland Turbo Pascal.

In those early days of the 1980’s, memory wasn’t an infinite field; it was a precious, finite resource. While most of us were content living with the structured guardrails of BASIC, there was a subset of us drawn to the elegant, stripped-back world of FORTH.

Learning FORTH felt less like coding and more like learning a new way to breathe. It was lean. It was efficient. It stripped away the overhead of high-level syntax until it was just you, the dictionary, and the stack. There was an honesty to it—no hidden abstractions, just a direct conversation with the hardware.

Then, of course, there was the hurdle of Reverse Polish Notation (RPN). Grokking the stack meant rewiring your brain. You couldn’t just state an operation; you had to prepare the world for it first. You pushed your data onto the stack, one piece at a time, and only then did you call the action. It was a rhythmic, almost percussive way of thinking: Input, input, act.

“In FORTH, you don’t just write programs; you build a language to solve the problem.”

This “bottom-up” philosophy changed the relationship between the creator and the machine. You weren’t just a user; you were an architect of your own vocabulary. To define a new “word” in FORTH was to permanently expand the capabilities of your environment. It was a recursive journey where every small success became a building block for the next complexity.

Looking back, those days with the IBM PC and the stack weren’t just about efficiency. They were about the discipline of clarity. When resources are limited, your thinking must be precise. The difficulty of RPN wasn’t a bug—it was a feature that forced you to understand the flow of data at its most fundamental level.