Build Faster, So You Can Understand More Deeply

Eren Asena recently asked me the following question on Twitter:

To what extent does the abstraction of code through libraries prevent understanding? How to balance building faster and understanding more deeply?

I’m republishing my response here.

Many assume that deeper understanding comes from diving into the guts of a subject. This isn’t a good understanding of how information works. Diving deeper isolates your understanding, keeping your knowledge out-of-context and sterile.

The ability to discern comes from seeing a concept play out under varying contexts. Seeing what stays the same when everything else changes. The abstraction of details towards usable tooling is what makes genuine learning possible.

It’s what brings you *into* the real world, up against the need to contend with a multitude of factors. When you build you see what survives. THIS is how understanding is achieved under complexity.

The epistemic barriers in nontrivial situations preclude the very notion of “going deeper”; deep knowledge cannot be attained by focusing more intensely on a singular topic. Only through repeated exposure under real world stress does viable information emerge.

Using libraries/frameworks/APIs is what it means to make software today. Those who spend time in the detailed guts of code, *before* attempting to build something real, stay there. They never expose what they’ve read to real-world stressors.

Their so-called deep understanding is illusory; a narrative that only sits comfortably in isolation. So always prioritize building real things over going deeper into a subject. Building is something you can control, but true comprehension only emerges through repeated trial.

Build faster, so you can understand more deeply.