Wisdom Can Be Learned, Not Taught

There are two kinds of knowledge, and most of how we educate, hire and promote people depends on mixing them up.

Declarative knowledge is anything that can be declared: written down, spoken aloud, passed from one person to another. Every book you have ever read is declarative knowledge. So is every lecture, every manual, every wiki page and every PRD.

Procedural knowledge is what you know because you did it. You learned it with your hands, over time, often by getting it wrong first. It lives in you, not on a page.

I didn't coin these terms. The philosopher Gilbert Ryle drew the line in The Concept of Mind (1949), as "knowing that" versus "knowing how." Cognitive scientists later named the two halves declarative and procedural, most notably John R. Anderson in his ACT theory of the mind (1976). And the chemist-turned-philosopher Michael Polanyi put the heart of it in one line: "We can know more than we can tell" (The Tacit Dimension, 1966).

This difference is the key to something I keep coming back to: engineering was never about coding. It is about judgment. Some would call it wisdom. And judgment is procedural knowledge, earned over years and often decades of practice.

We love declarative knowledge, and we should

Declarative knowledge was a revolution in its own right. It began when someone first pressed marks into wet clay, and writing let one person's knowledge outlive them and travel to people they would never meet. Gutenberg didn't invent that revolution. He sped it up. Writing, and the spread of knowledge through writing, has shaped every society we have built since.

Declarative knowledge has real value. It lets you skip much of the long road the original knowledge took. It can gather the many dialects of wisdom from many sources and harmonize them into something more coherent, more logical and more durable than any one of them.

We live and die at the altar of declarative knowledge. Look at our institutions of learning.

A book is a shadow of what its author knows

Before someone can sit down to write a book, they need to spend twenty years out in the proverbial field with their subject. They get their hands in the dirt. They sit out in harsh conditions. They go down false trails. They talk to others working the same field: what have you learned, what have you seen?

Then they take all of those field notes, experiences and even feelings, and try to express something very real, very raw and very organic as abstractions in a written language. Or, if they are an orator, they get up on a stage and share it with a listening audience.

Until that book is published or that lecture is given, all of that knowledge is procedural for them. They learned it by doing. Only then can you and I come along, pick up a nicely signed copy, and sit in our favorite chair at home to learn from it.

Writing it down transforms that knowledge. What was messy and tangled up with personal experience and emotion becomes more detached and more universal, something any other person can relate to and learn from.

But make no mistake: it is a distillation. Procedural knowledge is a wild landscape, a messy forest of trees, bushes and grasses, with its unknowns waiting to pounce on the wary traveler. The book is a neatly groomed garden that anyone can safely stroll through at their leisure. All the wild things are kept outside, or locked in cages with clear signs: "Don't put your hand in here, lest it be eaten!"

The pruning matters. It is also exactly what makes the garden safe, and exactly what the garden cannot teach you.

Can we, or should we?

Go back to that four-year degree, or that twelve-week course to learn to code. It was a pass to get you through the door.

We soften the title "engineer" with qualifiers: intern, junior, senior, staff, senior staff, principal, senior principal, distinguished. It takes time to work through those titles, and for good reason. The role of engineer, like lawyer or doctor, or a trade like plumber, electrician or home builder, is more than a set of skills. It is more than coding. It is more than a doctor's "stick out your tongue and say ahh." It is more than the hammering, sawing, cutting, ripping, jamming and tiling of a home builder. (Trust me, that's what they're called by those in the know.)

The role is knowing when to do something, as much as when not to.

In software in particular, I hate the question "Can we do X?" It's software. Short of breaking the laws of physics, software is an infinitely abstractable, infinitely mutable medium. The answer is a resounding yes.

The interesting question, the one that deserves real consideration, is "Should we do X?" That question is about judgment. It is about pattern recognition. It means balancing a long Pareto of demands: sellability, marketability, operability, usability, maintainability and more. It quietly treats time as one of the many resources we have to balance.

You can't learn that from a textbook. You can learn about it. But learning about something is not the same as learning the thing.

That is wisdom. Wisdom can be learned. It cannot be taught. The thing itself is procedural.

So yes, you have a four-year degree. You learned a lot. Some of it was skills. Much of it was learning about what you will meet later, so you are better prepared when you reach those forks on the job. But the almighty book cannot transmit wisdom.

Why this matters now

In 2014, the economist David Autor gave Polanyi's line a name: Polanyi's paradox. We can't automate what we can't explain, and we know far more than we can explain. For decades, that was the line between the work machines took over and the work they couldn't touch.

LLMs have moved that line. They have read nearly every book, every manual and every answer anyone ever posted. In other words, they hold more declarative knowledge than any of us ever will. But they hold it the way a book does: as the garden, not the forest. The "should we" still lives on the far side of Polanyi's line.

AI, and specifically LLMs for the pedants out there, has greatly amplified our ability to do things. But it doesn't amplify everyone equally.

Say a new hire is twice as productive with an LLM. A seasoned pro, with ten to twenty years behind them, might be ten times as productive with one. If that pro was already ten times the new hire before AI, the gap is no longer ten to one. It is a hundred to two: a fifty-fold divide.

At that gap, it is nigh on impossible to make the economic case for a new hire within a quarterly or annual budget. So, as an industry, we face a crisis. It isn't news. We saw it coming, and now we are watching it play out, quickly. Our pipeline of new hires has stalled.

And the time it traditionally took to grow a new hire into a staff engineer was on the order of fifteen years. Maybe five, if we say a senior engineer is independent enough without yet being a walking army of one.

The problem is that doing is how you learn. Doing is how procedural knowledge, wisdom, is acquired. And wisdom is what separates a new hire from a seasoned pro in any profession.

Code was the vehicle

I've written before that code was never the point. The wisdom never lived in the coding.

But coding was a vehicle. It let you move around inside a very large structure, a system of systems, and learn from the inside out, in a deeply experiential way, what does and does not work. You were building pattern recognition. You were making connections and cementing them into muscle memory.

You learned which wires carried 200 volts and could kill you, so you went slow, and which carried 12 volts, where who cares if you got zapped. You learned which decisions were one-way doors, almost impossible to undo once made, and which were two-way doors, where it was better to just do something, anything, than to over-analyze and over-research.

And you learned a thousand, a million, other things through the hundreds and thousands of decisions you had to make, because the PRD from your PM and the mocks from your designer were only broad brushstrokes. They gave you the composition, the subject and the color scheme. As an artist-engineer, you had to work out how to fill all of it in with fine detail.

Accountability matters too, but that is a different thing. It comes largely from character and a sense of integrity, not from practice. This post is about the knowledge, not the person holding it.

Ideas, not answers

I honestly don't know exactly how to solve this. But I have ideas.

The first is to rethink how we take new hires to senior, or even staff, far more quickly than fifteen years, while keeping them working with LLMs as their daily driver. Some of those ideas are going into what we build at Monster Orange: Den, Den Hub for teams, and later Den Enterprise. Right now our focus is Den and Den Hub.

The second is bigger than any one company. As an industry, I think we need foundries.

A foundry would sit between the four-year degree and the twelve-week coding school. People would come to learn side by side with seasoned veterans. They would learn the best practices of agentic engineering. And at the same time, they would start to earn the in-the-trenches understanding of what engineering is really about: the wisdom of system-of-systems thinking, alongside building real things, practically, for a cohort of partner companies.

After a year, they would leave the foundry for full-time roles at those companies. Not as senior engineers, but as something much closer to senior in critical thinking and decision-making than any new hire we have ever minted with a degree alone.

The trades have always known this. Plumbers, electricians and home builders learn as apprentices, beside someone who has already been zapped by the 200-volt wire. Software spent decades pretending it didn't need that, because the code itself kept us in the field long enough to learn. Now that agents write much of the code, we need to build the field on purpose.

That means investing in mentoring. We always have. Some of us feel a calling to give back to those coming up behind us. I know I do.

But it's hard to square mentoring with the need to work full time. It used to work because companies relied on internal pipelines, hiring interns and growing them, and by the nature of that pipeline, mentoring had to happen for everyone to succeed. Without that pipeline, we have to build it ourselves, and figure out how to make it work for the benefit of all of us, collectively, as an industry and as a society.

And I still advocate learning to code. Not for the act itself, but for what you learn through the act. It gives you a perspective, and a language, for the things that matter in engineering, which is all about system-of-systems thinking.

If you're like me, and you have ideas, please reach out. I'm interested in helping in any way I can.