Why I Learned to Think Like an Engineer
My Journey From Memorizing Docs to Internalizing Systems in a World Obsessed with Speed
For such a long time, I had the conviction that learning meant raw speed, and I focused obsessively on extreme efficiency.
If I could blaze through tutorials, skim documentation faster than the next dev, maybe even knock out an online course in record time, then surely I was making progress, right?
But in hindsight, I started to realize that I wasn’t learning anything. I was hoarding. I was stockpiling enormous amounts of facts and snippets without any kind of structure to hold them together.
Like caching a million return values without ever understanding the function that generated them. It felt productive (I was "doing stuff" all the time) but in practice, I was just wiring my brain into a brittle, shallow architecture.
The real irony is that this chase for speed actually undermined both my productivity and my knowledge.
I could recall many keywords but not concepts. I could mimic patterns but not modify them.
I could use tools (well, kind of) but only in the exact way they were shown to me.
The moment something broke or behaved unexpectedly, I was lost. I’d spend hours Googling symptoms, not because the bug was hard, but because I didn’t understand the system deeply enough to even ask the right questions.
I didn’t just feel stuck. I felt very fragile.
It took me a while (and some real frustration) to realize that engineering isn’t about memorizing tools or racing through materials.
It’s about building mental models, like coherent, flexible frameworks that help you reason through complexity. And those don’t come from sprinting. They come from slow, layered, deeply felt understanding.
From pausing to ask “why” even when it feels inefficient. From sitting with a problem until your brain starts seeing it from the inside.
In a sentence: speed gave me the illusion of competence. Slowness gave me the substance of it.
From Documentation to Deduction
I still remember the first time I tried to debug a Kafka partitioning issue. The data wasn’t flowing the way I expected, and every online answer felt like a surface patch: “Try this config”, “It’s probably a consumer group thing”, or “Reset the offsets.”
But why? What was actually happening under the hood?
I finally paused everything, printed a whiteboard diagram, and sat down with the actual source code (in this case not a blog post, not a Stack Overflow thread), the raw implementation.
It was messy. I didn’t even understand half of it.
But I stayed with it.
Many hours later, I understood why that consumer was lagging.
It wasn’t just a tweakable setting. It was a symptom of a misaligned mental model I had: one that assumed consumption was stateless, when in reality, Kafka clients form a deeply stateful and coordinated dance.
That day taught me something: intuition is what remains when Google is gone.
It’s the difference between copying a solution and sensing one.
System Fluency, Not Syntax Speed
I started approaching technical work differently after that. Instead of chasing hacks and shortcuts, I began studying systems like languages.
Kafka, Kubernetes, Airflow: each has its own grammar, metaphors, and a deep internal logic. And like learning a new language, true fluency only comes from immersion, not with mere memorization.
For example, I stopped treating Airflow like a bundle of YAML configs or a pipeline execution engine. I started visualizing it as a living DAG of dependencies, more like a mechanical watch with intricate gears ticking in sync.
I’d sketch out workflows by hand. I would interrogate them as if they were thought experiments:
“If I pull this task forward, what’s the chain reaction?”
“What failure modes live here?”
“What assumptions am I quietly making?”
This wasn’t fast. In fact, it was embarrassingly slow at times. But something unexpected happened: the knowledge began to shift from “what to type” into “how the system thinks.”
I’d be biking or making coffee, and out of nowhere a somewhat better DAG layout would just click into place.
That’s when I realized I was no longer just using the system. I was slowly starting to think in it.
Cognitive science actually backs this up. Research from Anders Ericsson, the renowned pioneer of deliberate practice, shows that expert performance isn’t about raw repetition or speed, but about slow, structured engagement with increasingly complex problems.
Mastery requires what he calls mental representations: compressed internal models that let you simulate, predict, and reason about a domain.
This process is also reflected in the work of John Sweller on cognitive load theory.
When we rush through tutorials or code by rote, we overload our working memory, simply because we can’t hold enough context to truly grasp system interactions.
But when we slow down, engage visually, and reflect, we offload information into long-term memory structures that allow for automation of reasoning. That’s when intuition begins to form.
Even many studies in second-language acquisition echo this: true fluency arises not from memorizing vocabulary lists but from internalizing the grammar (the system’s rules, rhythms, and exceptions) through contextual immersion.
When I began thinking of tools like Airflow or Kubernetes as languages with syntax, semantics, and idioms, I naturally adopted more effective learning strategies: sketching, dialoguing with the system, spacing out sessions for consolidation.
Neuroscientist Maryanne Wolf calls this “deep reading” of systems: a slow, recursive, and effortful style of cognition that activates the brain’s default mode network, prefrontal cortex, and anterior cingulate, allowing us to not just absorb but integrate information into a broader model of meaning.
In other words, you have to remember this: slowness isn’t inefficiency. It’s the substrate for creativity, insight, and durability of knowledge.
So yes, I was deliberately moving slower. But I was also building architecture in my head; mental observability tools, model-based debugging instincts, and a kind of quiet confidence that only came from thinking with the system, not just working on it.
Why Speed Doesn’t Equal Mastery
Modern learning environments push pace. Courses have to promise mastery in hours. Tutorials are now measured in minutes. Stack Overflow rewards fast answers, not deep, technical ones.
But depth runs on a different clock.
It demands time spent in ambiguity — sitting with the uncomfortable fog of not knowing, resisting the dopamine rush of quick resolution.
Building intuition is metabolically expensive. It’s the intellectual equivalent of strength training: microscopic tears in your mental model, followed by rest, integration, and growth.
Cognitive psychologist Daniel Kahneman described this difference in Thinking, Fast and Slow:
“Intuition is nothing more and nothing less than recognition”.
And to stick with it, recognition (he argued), doesn’t come from speed-reading a tutorial, it comes from slow, repeated exposure, pattern-matching, and internalization over time.
This is echoed in Barbara Oakley’s research on learning: the brain toggles between focused mode (effortful, active thinking) and diffuse mode (relaxed, unconscious integration).
To build true insight (real, aha-type understanding) we must first stay in the problem long enough for it to sink into both.
I now deliberately choose to “stay in the problem” longer than feels efficient. If I’m debugging a flaky data pipeline, I don’t just patch the issue.
I sketch out the counterfactual:
What if the S3 connection had failed?
What should have happened?
What assumptions failed to hold?
This kind of thought experiment isn’t just hypothetical play: it’s a deliberate practice. Neuroscientist David Eagleman, renowned for his research about time perception, brain plasticity among others, puts it this way:
“The brain is a prediction engine.”
When we simulate alternate realities, we’re not wasting time: we’re training our internal models to become more robust and fault-tolerant.
Psychologist Gary Klein, who studied decision-making in high-stakes environments like firefighting and aviation, found that experts often rely on a process he called mental simulation: imagining how a situation might unfold, where it might go wrong, and how to intervene.
He writes in Sources of Power:
“Mental simulation is the ability to imagine people and objects consciously and to transform those people and objects through several transitions, finally picturing them in a different way than at the start.”
This process builds the so-called “cognitive resilience”, not just solving problems, but understanding the space of problems.
So now, I don’t rush to fix. I trace. I model. I counterfactual. I ask not only what broke but why it broke in exactly this way, and what other dimensions could have produced a similar failure.
It's undoubtely slow. But this slowness is capable of building something speed can’t: a mental debugger, an internal compass that orients me even in unfamiliar terrain.
And strangely, over time, the work starts to feel lighter. Not because the problems are easier. But because I’ve trained myself to see more clearly.
I carry more of the system in my head, and I can simulate deeper and faster, not because I had to memorized more facts, but because I invested in deeper models.
To paraphrase Einstein:
“It’s not that I’m so smart. It’s just that I stay with problems longer.”
Thinking in Layers
Another thing that helped: learning to think in layers.
Early on, I’d approach technical systems like monoliths, like “ Okay, I want to learn Kubernetes”, or “Let’s now optimize Prometheus” full stop.
But that’s like saying you want to learn advanced biology concepts, like CRISPR, in a weekend, and unless you’re Jennifer Doudna, you can’t (though I suspect even she took several years to fully master her domain).
It’s not one thing; it’s a stack of abstractions, each with its own vocabulary, logic, and failure modes. What finally shifted my learning was slicing the system into conceptual layers, and letting myself occupy them one at a time:
Surface: How do I deploy something? What commands do I run? What does the YAML look like?
Middle: How do the primitives relate? What’s the role of Pods, ReplicaSets, Services, ConfigMaps?
Deep: What’s the control plane doing under the hood? How does the reconciliation loop work? What happens when etcd flakes or the scheduler gets overwhelmed?
This multi-altitude approach did something subtle but powerful: it gave my brain space to scaffold its understanding. Instead of forcing a premature sense of mastery, I let comprehension mature layer by layer, like sediment forming bedrock.
And neuroscience supports this.
Memory researchers like Robert Bjork have shown that “desirable difficulty” (slowing down to switch perspectives or struggle with abstraction) actually improves long-term retention.
It’s not just repetition that builds mastery, but interleaving: alternating between levels and contexts, which strengthens the neural pathways connecting facts to concepts.
Ray Kurzweil, in How to Create a Mind, echoes this with his theory of the neocortex as a hierarchical pattern recognizer.
According to Kurzweil:
“The neocortex is organized in a hierarchy, with higher levels recognizing more abstract features. Learning occurs by building successively more abstract representations from sensory data.”
In other words, we don’t just remember facts, instead we build mental models, and we do it hierarchically. The surface layer teaches us what’s visible. The middle layer helps us form patterns. The deep layer lets us reason and anticipate.
Once I embraced this, I gave myself permission to not know everything at once. I’d consciously ask myself: What altitude am I learning at today? Sometimes I’d just sketch how traffic flows between Pods.
Other days I’d stare at the kubelet logs, trying to understand why a node thought it was healthy when it wasn’t. And gradually, the fog began to lift, not because I memorized Kubernetes, but because I could think with it, in layers.
It’s also why, these days, I teach that way. Whether it’s Airflow, Kafka, or Rust, I try to break the learning journey into altitudes:
What can you do with it? (surface)
What are its moving parts? (middle)
What are the design trade-offs and implicit contracts? (deep)
Thinking in layers doesn’t just make the system easier : it makes your thinking more composable. When something breaks, you’re not guessing randomly. You can zoom in and out, asking: Is this a problem of configuration, orchestration, or control logic?
You start navigating by structure, not just memory.
And that’s when real fluency begins: not when you know all the layers, but when you know which layer to reason in.
The Power of Rewriting
One practical habit that quietly supercharged my learning was this: rewriting what I’d just learned, entirely in my own words.
Every week, I’d pick one concept I thought I understood (say, how Airflow schedules tasks), and try to explain it on a single page. No jargon, no code, no borrowed phrasing, just plain language and a sketch or two.
Sometimes I’d hit a wall halfway through. “Wait... what does the scheduler do when two DAGs depend on the same task instance?” That moment of hesitation was gold. It wasn’t a failure, I viewed it more as a flare. A signal that my understanding had weak spots I’d papered over.
This practice is a form of active recall, but I think of it more as constructive forgetting. You unearth the assumptions you didn’t realize you were making. You expose the blind spots you didn’t know you had. That’s the start of real intuition: the hidden power of not just remembering facts, but feeling how the system wants to behave.
And when you explain it, you’re essentially doing the mental version of test-driven development. If your model of the system can’t survive the test of clarity, if it buckles under plain English and simple sketches, then it’s probably not ready for production in your brain.
So I keep rewriting. Not to make notes prettier, but to build better mental code.
Engineering for Intuition
Now, when I onboard into a new codebase or tool, I don’t ask: “How fast can I learn this?”
I tend to ask: “What’s the underlying model? What metaphors does this system run on?”
Then I start building little “mental widgets”:
Mental diagrams I can animate in my head (e.g., what happens when a Kafka broker dies).
Mini-case studies from production bugs; not just what failed, but why I didn’t predict it.
Handwritten summaries of components, almost like flashcards for systems.
The goal isn’t to memorize as many things as possible, it’s to internalize.
And once internalized, those concepts become mere mental primitives.
You start reaching for them automatically.
Like how a musician doesn’t think “C-E-G”, they just hear a chord.
Slowness is a Feature, Not a Bug
So if you’re learning something right now and it feels slow, it’s good.
That friction you’re feeling? It means your brain is doing the real work: forging durable, long-term representations instead of stacking shallow facts.
The best engineers I know aren’t the ones who blaze through docs or churn out PRs the fastest. They’re the ones who are deliberate.
They pause. They ask why, not just how.
They can explain complex systems in terrifyingly simple terms, and not because they memorized more, but because they internalized more.
That kind of clarity doesn’t come from sprinting through tutorials.
It comes from living inside the system, poking at its edges, mapping its failure modes, seeing how the parts cohere under pressure.
So take your time.
Build mental models. Draw diagrams. Break things on purpose. Rewrite what you think you know, until the fuzziness clears.
Trade speed for understanding.
Because in the long run, intuition compounds, and nothing scales like that.
—Lorenzo