I had a 1-on-1 recently with a brilliant engineer, and he asked me about getting to the next level of technical understanding. You know, not just “using” the technology, but understanding it deeply and creating something new. That caused me to think: how do you go deep?
Nailing down the goal
When I want to learn something new, I usually start by ”whetting my whistle” — grabbing a quick article or a 5-minute video to see what the fuss is about. This is the triage phase. I’m discerning: Is this a rabbit hole worth falling down, or just a shiny object I can safely ignore?
If I decide to go further, I have to be ruthless about the destination.
The problem with most technical topics is that they are fractal; the closer you look, the more complexity you find. If you set out with a vague goal like “I want to learn Python,” you’ve already lost. Python is an ocean. Without a compass, you’ll spend three weeks learning how to sort lists and three months wondering why you don’t feel like an “expert” yet. You’ll drown in a sea of information, convinced that true mastery is impossible.
To go deep, you have to shrink the surface area.
Instead of “Learning Python,” your goal should be: “I want to learn FastAPI so I can ship an application idea I have.” By narrowing the focus, you transform an infinite task into a solvable puzzle. You aren’t just wandering through the woods anymore; you’re building a specific path. A narrow focus doesn’t limit your growth; it fuels it. It gives you a “win” state, and in the world of deep learning, momentum is everything.
Knowing by reading
Once you’ve narrowed your goal, say, mastering FastAPI, the temptation is to binge-watch tutorials at 2x speed. Resist that. Going deep requires shifting from “reading for information” to “reading for intent.”
Most people read documentation to find a specific answer to a specific problem. That’s “User” behavior. To go deep, you have to read like an architect. You aren’t just looking at the what; you are hunting for the why.
The Rationale over the Syntax: Don’t just memorize the commands. Seek out the “Design Philosophy” or “Architecture” pages. Why did the creator choose this specific path? Understanding the constraints the author faced tells you more about the tool than any tutorial ever could.
The “Wait, How?” Test: As you read, pause every few paragraphs and ask: “If I had to build this specific feature today, how would I even start?” If you can’t visualize the logic, you’re reading too fast. You’re scanning, not absorbing.
Reading the “Ancients”: Technology is a conversation. Today’s tools are answers to yesterday’s problems. If you’re joining a new company, don’t just read the current code; come up with a list of questions a more senior engineer can answer why they wrote it that way. Seeing how a system evolved (and what mistakes were fixed along the way) provides a depth of context that a README simply can’t offer.
The Source Code is the Truth: Eventually, you have to stop reading about the thing and start reading the thing itself. Open the library’s source code. Seeing how a world-class engineer structures an internal function is like getting a private masterclass. It demystifies the “magic” and makes the technology feel like what it actually is: a series of logical decisions.
Knowing by tinkering
If reading builds the map, tinkering is actually walking the terrain. But there’s a catch: if you only walk the paved trails, you’ll never know what the ground is made of. To go deep, you have to venture off-road. You have to try to break things.
Most people follow a tutorial from Point A to Point B. If the light turns green at the end, they assume they’ve “learned” it. That is a trap. You haven’t truly learned a system until you’ve seen it fail.
Stress-Testing the Boundaries: Don’t just ask “Does it work?” Ask “When does it stop working?” If you’re learning FastAPI, don’t just send one request; send ten thousand. See where the latency spikes. See which part of the system starts to sweat. Understanding the breaking point is where true technical intuition is born.
The “What If” Game: This is the most powerful tool in an engineer’s arsenal. “What if I pass a string where it expects an integer?” “What if I kill the database connection mid-stream?” Every time the system throws an error, it’s handing you a piece of the puzzle. An error message isn’t a failure; it’s the system revealing its internal logic.
The “Black Box” Isolation: When you join a new company and the codebase feels like a giant, terrifying monolith, don’t try to understand the whole thing at once. Isolate one small function. Change a single variable. Comment out a line that looks important and see which “Check Engine” lights come on. This “controlled destruction” helps you map the invisible dependencies between parts.
The Sandbox Method: Create a “blank slate” environment. Try to replicate a specific behavior of the tool using as little “magic” as possible. If you can recreate a small piece of the functionality in a simple script, you’ve touched the core logic.
Knowing by creating
You can read every book on carpentry and tinker with every power tool in the shop, but you aren’t a carpenter until you’ve built a house that stays standing in a storm.
In engineering, creating is the ultimate filter. It’s where you realize that “theoretical knowledge” is often just polite-speak for “not knowing yet.” When you create, you are no longer following a map; you are drawing one for others.
Synthesis, Not Just Mimicry: True depth isn’t just building another “To-Do” app. It’s taking a pattern from one area and applying it to a data pipeline. You know you’ve gone deep when you can translate concepts across domains to solve a unique problem.
The “From Scratch” Challenge: Going back to the FastAPI example, try to build a tiny, primitive web server using nothing but standard Python libraries. When you have to manually handle headers and sockets yourself, you gain a profound respect (and a deep understanding) for why the “expert” tools exist. You stop seeing the tool as a black box and start seeing it as a collection of architectural decisions.
Teaching as the Ultimate Test: You haven’t truly mastered a topic until you can explain it to a non-technical stakeholder or a junior dev. Creating a tutorial, a diagram, or a presentation forces you to find the “missing links” in your own understanding. If you can’t explain the why simply, you haven’t gone deep enough yet.
Closing the loop
I told that engineer that the ‘next level’ isn’t a secret club or a specific certificate. It’s just the willingness to stay with a problem long enough to understand it deeply enough that you can start reusing patterns. It’s the transition from asking ‘How do I use this?’ to ‘How was this built, and how can I build it better?’
📝 In Case You Missed It…
I’ve been diving back into test-driven development as a practice and am taking notes along the way.
Thomas Aquinas, Doctor of the Catholic church, argues for the existence of God with his “five ways” in his most popular work, the Summa Theologica.
📚 What I’m Consuming
How to force yourself to be consistent and do hard things (video). Design the system. Become the system. Scale the system. Easier said than done.
Traits of a good Tech Lead (article). The author clearly differentiates between the tech lead and the engineering manager in terms of their key responsibilities, which I found valuable.
Creating your own opportunities (article). I give this advice all the time. Opportunities aren’t often handed on a silver platter at work. Often, you have to make your own opportunities for growth.
Peace be with you,
Jacob
psst… hey, could you forward this to someone you think would find it valuable? I’d greatly appreciate it!