For about four years I was a tourist in my own career.
Every few months a new framework would trend, and I'd drop whatever I was learning to chase it. New state manager? Rewrote my side project. New meta-framework? Started a fresh repo. New build tool that was "10x faster"? Spent a weekend on config and shipped nothing.
I had a hundred starting lines and almost no finish lines.
The thing that finally broke the spell wasn't discipline. It was watching a colleague who knew one stack deeply run circles around me — not because his tools were better, but because he'd stopped renegotiating his foundations every quarter.
Chasing every new framework feels like learning but mostly keeps you a permanent beginner. The fix is to go deep on one stack until you understand its trade-offs cold, learn the durable concepts underneath the tools (not the syntax), and adopt new tech only when it solves a problem you actually have. Depth compounds. Novelty resets.
Switching frameworks resets your level to zero every time.
Beginner-level is comfortable in a sneaky way. The tutorials are dopamine. The "hello world" runs on the first try. You feel productive because everything is new and shiny and easy. But you never reach the part where the framework fights you — and that part is where actual expertise lives.
I had built maybe a dozen to-do apps across a dozen stacks. What I had never done was take any single one of them to the point where I hit its real limits, its weird edge cases, its production failures at 3 a.m.
You don't understand a tool until it has hurt you. Tourists never stay long enough to get hurt.
Here's the reframe that fixed me: frameworks come and go, but the ideas under them barely move.
Caching, data modeling, concurrency, idempotency, how a request actually travels through a system — these don't expire. Learn them once, properly, and every new framework becomes a translation exercise instead of a from-scratch rebuild. The new thing is just old ideas wearing different syntax.
This is the same depth-over-novelty bet at the heart of the brutal truth about becoming a senior developer: the durable skills are the ones worth compounding. The annual ThoughtWorks Technology Radar reads very differently once you can map new tools onto ideas you already understand instead of treating each one as a fresh emergency. When I finally understood how rendering and data-fetching actually worked at the concept level, every "revolutionary" framework that came out afterward looked the same to me. Oh, this one moved the work to the server. This one cached more aggressively. This one renamed the same lifecycle. Suddenly I could evaluate them in an afternoon instead of adopting them in a panic.
The shiny developer tools didn't get less interesting. They got less scary, because I finally had a stable place to stand while I judged them.
Going deep on one stack changed concrete things, fast.
Here's the trade I was unconsciously making, made explicit:
| Chasing novelty | Building depth |
|---|---|
| Always a beginner | Eventually an expert |
| Many starts, few finishes | Fewer starts, real finishes |
| Evaluate by hype | Evaluate by trade-offs |
| Resets every quarter | Compounds every year |
I didn't become a luddite. I just added a gate.
Before I'll seriously learn a new framework, it has to clear three questions:
If it passes all three, I go deep on it — not skimming, but actually building something that hits its limits. If it fails any of them, I bookmark it and move on with my life.
A lot of framework hype is just churn.
The ecosystem has an incentive to make you feel behind. New tools need adopters, conference talks need topics, and "you're using the old way" is an effective way to manufacture urgency. Some of it is genuine progress. A lot of it is fashion with a changelog.
Once I stopped treating every release as a referendum on my competence, I noticed how much calmer and more productive I became. The work got better. My side projects shipped. And ironically, because I understood the fundamentals so well, I could pick up genuinely new tools faster than the people who'd been chasing all of them.
A small amount of automation helped me resist the noise — I funnel new-tool announcements into a single weekly digest instead of a real-time firehose, and review them once, deliberately, when I'm not mid-task.
I want to be concrete, because "go deep" is easy advice and vague action.
For me it meant taking one web framework and one database and refusing to switch for a full year, no matter what shipped. During that year I deliberately chased the uncomfortable parts. I profiled a slow endpoint until I understood exactly which query was the problem and why the framework was issuing it. I read the source of the framework when the docs ran out — not all of it, but enough to stop treating it as a black box. I deployed the same app enough times to automate the deploy, then broke the deploy and fixed it, which taught me more about how the thing actually ran than any tutorial.
I also kept a running file of "things that surprised me." Every time the framework did something I didn't expect, I wrote down what I'd assumed and what was actually true. By the end of the year that file was the most valuable document I owned — a personal map of where my mental model and reality diverged.
The result was a strange kind of confidence. When a teammate hit a weird bug in that stack, I usually had a hypothesis within minutes, because I'd already wandered through most of the dark corners. That's the payoff novelty-chasing never gives you: not knowing more tools, but knowing one tool so well that surprises become rare.
It also changed how seriously people took me. There's a particular respect that goes to the person who actually understands the thing everyone else only uses. I became the one who got pulled into the hard conversations, not because I knew more frameworks than anyone, but because I knew our framework deeper than anyone. That depth is a reputation you can only build by staying put long enough to earn it.
And it freed up an enormous amount of mental energy I hadn't realized the chasing was consuming. When you're constantly half-learning new tools, a low-grade anxiety runs in the background — the sense that you're always behind, always one release away from obsolete. Committing to depth quieted that voice. I stopped feeling behind, because I'd stopped measuring myself by how many tools I'd touched and started measuring by how well I understood the ones I used. That calm, more than any skill, was the part I wish I'd reached years earlier.
Depth isn't memorizing a framework's API. It's having already met its ghosts, so nothing it does scares you anymore.
And here's the compounding part. Once I'd done this once, doing it for a second tool was twice as fast, because half of what I'd learned wasn't really about the first framework — it was about how frameworks work in general. Depth in one place quietly became breadth everywhere.
If trading framework FOMO for real depth resonates, consider sticking around for more field notes on building skills that compound instead of reset.
Q: Won't I fall behind if I ignore new frameworks? The opposite, usually. Deep fundamentals let you learn any new framework quickly when it matters. Shallow tourism leaves you perpetually re-learning the easy part.
Q: How do I know when I've gone "deep enough" on a stack? When you've hit its real limits — performance walls, ugly edge cases, production failures — and understand why they happen. If everything's still working perfectly, you haven't pushed it hard enough yet.
Q: Isn't some new tech genuinely better? Yes, and the gate is designed to catch exactly that. Real improvements that solve real problems pass the three questions easily. Fashion fails them.
Q: What about staying employable? Employers hire for problem-solving and depth far more than for a specific framework. The person who deeply understands one stack interviews better than the one who's touched ten.
Novelty feels like growth, but it's often just motion. The developers who pull ahead aren't the ones who learned the most frameworks — they're the ones who understood a few things so deeply that every new tool became easy.
Pick a stack. Go past the tutorials, past the comfort, all the way to the part where it hurts. That's where you stop being a tourist and start being an engineer.
What's one tool you've started five times but never actually finished learning?
I spent years saving the hardest task for when I 'felt ready.' Doing it first instead quietly fixed my focus, my dread, and my output.
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
I tracked every distraction for a week and was horrified by what I found. Then I fixed the three that mattered most.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!