Filtering the hype: you don't have to learn every new technology
How to manage your learning budget against the constant pressure of new tools and frameworks — a practical approach to deciding what to learn and when.
As a developer in 2023, you encounter something new every single week. A new JavaScript framework, a new AI tool, a new language feature, a new paradigm. On social media, everyone seems to be learning it. If you’re not, are you falling behind?
The assumption hiding inside that question is this: learning capacity is unlimited — it’s just a matter of time and intention. That’s wrong. A learning budget is finite; attention, energy, and focus are constrained resources. If you spread them across every shiny new thing, you’ll never go deep on any of them.
This isn’t a motivation problem. It’s a prioritization problem.
What we feel when a new technology appears
The first reaction usually falls into one of two camps: excitement or anxiety. Excitement comes when you think, “if I learn this, I can solve that problem.” Anxiety comes when you think, “if I don’t learn this, I’ll get left behind.”
Learning that starts with excitement usually gets somewhere. Learning that starts with anxiety often never gets off the ground — or it starts and fizzles out halfway. Without realizing it, you’ve turned your learning list into a graveyard of “I wish I’d learned that.”
The real problem, in my view, is this: there’s no clear criterion for deciding which technology to learn. Without a criterion, making a decision is hard, and every new thing that shows up triggers the same anxiety all over again.
A practical filter
Before I commit to seriously learning a technology, I ask myself three questions:
Does the problem it solves overlap with my own problems?
If the answer to this question is “no,” the learning rarely generates value. A tool or framework exists to solve a specific problem. If you don’t experience that problem, you won’t use the tool even if you learn it — and what you don’t use, you eventually forget.
Let me make that concrete: GraphQL is a powerful tool. But the client-server data dependencies in the projects I work on don’t create the problem GraphQL was built to solve. So I know GraphQL at a surface level, but I haven’t invested serious time learning it deeply. That’s not a shortcoming — it’s a deliberate choice.
Is the ecosystem mature?
Learning an immature ecosystem early can sometimes be an advantage, but it’s usually costly: the API changes, documentation is incomplete, the community is small, and finding answers to your questions gets harder. Maturity means speed for you.
An easy way to gauge how mature a tool has become: look at conference talks from three years ago. Are they still relevant? If yes, it’s passed the maturity test.
Are the concepts transferable?
Look not just at whether what you’re learning is a specific tool, but at the underlying concept beneath it. If you learn TypeScript, you gain the ability to think in type systems — that transfers to Rust, Scala, and Go. If you learn a specific CSS framework, you learn class names that are unique to that framework; carrying that knowledge to the next framework is harder.
Investment in transferable concepts works like compound interest. Tool-specific knowledge depreciates.
The “I’ll look at it later” list
You don’t have to learn every new technology right away, but it’s worth keeping tabs on some of them. I maintain a short list for this purpose — I call it my “radar.” I hear about something, I understand roughly what it does, but I don’t spend serious time on it.
The simple rule for moving something from the radar to active learning: when a genuine need arises in a context where I’m actually working. Not abstract curiosity — concrete need. That transition is usually triggered by a project or a problem.
Investing in fundamentals
When you apply this filter, you’ll notice that most of the things truly worth learning deeply aren’t new. HTTP, data structures, algorithmic thinking, type systems, concurrency models — none of these are recent releases. But someone who understands them well learns new tools dramatically faster.
How quickly you can move at the upper layers is directly proportional to how solid the foundation beneath you is. Learning a new tool that has passed any of these filters is, more often than not, just learning a new expression of a concept you already know.
You don’t have to learn every new technology. But you should have a clear rationale for what you do choose to learn. Decisions made without that rationale usually come from anxiety, peer pressure, or curiosity. All of those are valid motivations — but they each carry the risk of spending your learning budget without a plan. Being selective isn’t giving up on learning; it’s investing in learning.
Comments
Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.