One of the great frustrations with acquiring subtle knowledge is that it can’t be materially transferred.

The one thing that definitively characterizes crude knowledge is its ability to be rendered into books, blog posts, video materials, and the ability for anyone who consumes those materials to gain a certain measure of ability or fluency with the subject.

Subtle knowledge can’t be assimilated through material means. It can’t be converted into concrete materials the way that more basic and crude subjects can. The names of more subtle notions and their descriptions can certainly be written down, and they can even be demonstrated to an extent, but by no means does the presence of such artifacts allow someone else to be instantly augmented.

You can be told the names of subtle things, like design principles and design qualities, and you may even come to be able to recite their definitions from memory. But that is only memory. It is just intellectual inventory. It’s not necessarily actionable. It’s not something that you can put to use on-demand. Not until you’ve been reflecting on it for a while within the context of the particular circumstances your own hands-on work.

An intellectual inventory is a necessary precursor to having working knowledge of the subtle, but an intellectual inventory on its own only allows you to imitate and mimic the most externalizable and observable aspects of the work.

Being constantly distracted by the content of the intellectual inventory does little more than create an intellectual materialism, where valuing yourself and your abilities rests squarely on the volume of things you’ve memorized and put into your inventory without consideration of making them actionable. It creates a propensity to value the shallow acquisition of many new items of the inventory as quickly as possible, rather than gaining much transformative understanding.

Subtle knowledge is transformative. Crude knowledge is just cumulative. It’s necessary, but it’s only the very beginning. Subtle knowledge brings breakthroughs in understanding that changes the way you use all the more crude things you’ve learned. It changes how you do your work, and how you employ those crude, material items items of your intellectual inventory. Crude knowledge is those things that can be memorized from consuming the artifacts of someone else’s work. Subtle knowledge requires your willing participation to transform it into something as readily-actionable as crude knowledge.

At the crude end of the spectrum, you can get by on repeating and mimicking idioms and conventions. But it’s the subtle–the principles and the qualities that principles are built on-that tell you when the application of some crude thing is going to be the mistake that you only learn to regret in the future.

And yet, this incredibly powerful knowledge can’t be transfered from person-to-person by rendering it into materials. Only the crude can be converted to material. Only the basics can be transfered that way.

Gaining fluency with the subtle end of the spectrum takes practice and reflection. And this necessity is what rubs some developers the wrong way, turns them off the whole idea of going beyond the crude, and even makes them angsty and angry. Sometimes even to the point of denying the very possibility of the existence of the science of software design.

As we sharpen up our design senses, things that seemed to be imperceptible start to become obvious. Things that were distant and esoteric become close-at-hand to our work and readily-actionable.

It’s only because we haven’t been introduced to the more powerful aspects of software development that we tend to not actively pursue them as a matter of course for skills and career development. They’re imperceptible at first. They seem tiny and negligible. But as our senses become more acclimated to the subtle, the subtle things become as large and obvious as an elephant.

It’s the intentional improvement our ocular instruments that allows us to see subtleties as painfully-obvious things. And at that point, they’re not so subtle anymore. It’s only in retrospect that we still see them as subtle.

And even if you don’t understand the subtle and powerful side of the software development capabilities continuum enough to put them into action in your day-to-day work, you can still practice them merely by becoming aware of what they are, and paying attention to them. You can do this even if you can’t do anything about the problems with the software you work on. In fact, it’s a precondition for ever being able to have these subtle things available to your thinking in every moment, keeping you from mistakes, and transforming your more crude knowledge into something that doesn’t suffer from the pathological naiveté of intellectual materialism.

You need the crude. After all, you can’t built software without languages and tools and frameworks and patterns. But the subtle is the key in the lock that switches these crude things on and brings them to life and makes them powerful.

But you’re simply not going to absorb subtle knowledge by tucking a kindle under your pillow at night and hoping for knowledge to just leak into your being. Not are you going to acquire it through passive reception like reading or watching demos.

Gaining subtle knowledge is always a process of breakthroughs. The most powerful knowledge is the most subtle. And the most subtle is only ever realized through the kind of participation that allows for breakthroughs.

It won’t happen over night. But it won’t happen ever if subtle knowledge never gets the benefit of your attention.