Discovery
Thoughts on How to Learn New Things as a Busy Developer (and Why Good Conferences Are a Surprisingly Cost-Effective Way to Do It)
Here’s the problem: as a developer, there are quite a few things I already know how to solve. Some I know really well, and others, I’m rusty. I just remember the patterns for but haven’t touched them in years (like frontend code, which I haven’t written in ages).
There are even more things I don’t know, but at least I know that I don’t know them. These are domains I’ve bumped into before, understood the big picture, picked up some terminology, and moved on.
That’s actually one of my strengths as a senior developer: I don’t use the same hammer for every nail. Sometimes I face a new kind of problem, but I already know which tools or approaches exist to solve it. I might not know how to do it yet, but I know where to look, what keywords to search, and which tools are common. I have a mental map, or at least something to point my coding assistant toward.
But then there are the unknown unknowns: the things I don’t even realize I don’t know.
Those are dangerous. I might face a problem that clearly fits into a certain solution space, but since I don’t even know that space exists, I’ll use a solution that’s too complicated, too fragile, or just too expensive.
So how do we uncover those unknown domains?
How do we turn them into known unknowns, and maybe even knowns?
The Discovery Problem (and How It Connects to Growth)
Most areas in software are constantly evolving.
One example is the evolution of a framework or a programming language.I started writing Python when version 2.6 was still the standard, and “everyone knew” to avoid Python 3 because nothing really worked there. Today, the old 2.x releases (and the early, rough 3.x ones) feel like ancient history, and Python 3.14 has just been released.
This kind of evolution happens across almost every framework and language I’ve worked with. Some of it is within domains I already know, some expands my known unknowns, and some introduces entirely new tools that suddenly take over the world.
Using the Thoughtworks Tech Radar taxonomy (there are others, but this one’s excellent), we can group these changes into:
- Tools
- Frameworks and languages
- Techniques
- Platforms
In each of these, new paradigms emerge all the time. If you don’t stay aware of them, you get left behind — not just professionally (which makes finding your next role harder), but also in your current project. You end up building legacy code instead of using the right, modern tools.
Where Do New Things Come From?
Some innovations come from open-source projects that gain traction.
Some come from research, though very few of us actually read new academic papers.
Others come from frameworks released by big tech companies, or from mature developer communities (like Django or Postgres).
And all of this happens at an incredible pace. It’s nearly impossible to keep up.
LLMs won’t save us.
But isn’t this a solved problem ? LLMs Know Everything Now, Don’t They? Nope.
This is exactly the kind of thing LLMs are bad at.
They’re trained on massive existing knowledge bases, which means they tend to reflect “common” and slightly outdated code.
If you work in a slow-moving domain, that might be fine. But if you’re in a fast-changing field, it’s not enough.
Even if the LLM can answer something relevant, unless you already know how to steer it in that direction, it’s unlikely to introduce you to a new topic you’ve never heard of.
So What Can We Actually Do?
I started thinking about how my own discovery mechanisms work. What helps me learn and what doesn’t.
There’s a tension between relying on third-party curation and actively curating my own learning.
Get Alon Nisser’s stories in your inbox
Join Medium for free to get updates from this writer.
At one extreme, imagine a giant global RSS feed for all software.
New article? Ping.
New library version? Ping.
Yet another JS framework? Ping.
Obviously, that’s unmanageable. We need filters.
The Algorithmic Feed
One type of filter is the algorithmic feed: YouTube, Medium, Twitter (X), and so on.
You know how it goes: you read or watch a few things, and suddenly the feed is overflowing with more of the same.
The problem is that algorithmic curation is optimized for engagement, not value.
Clickbait titles and emotional content dominate.
We’ve all watched those YouTubers who start every sentence with “Now I’m going to talk about…” and end it with “So that’s what I talked about.”
Even worse, the algorithm amplifies what you already know and the topics adjacent to it, but rarely the faraway ones.
It deepens your existing bubbles and hides your unknowns.
Aggregators
A more intentional alternative is human-curated aggregators, like newsletters from Cooper Press.
They’re a bit like that imaginary RSS feed but with an editor acting as a filter.
The downside is that no one has time to read everything.
We’re back to the signal-to-noise problem: clickbait titles, repetitive topics, and content that mostly circles around what you already know.
This approach used to work for me, but less so today.
A more curated aggregation is projects like Tech Radar, with good curators, it can become a very good signal. Albeit it’s not a very clear signal, I hear the name of a tool, framework, etc, but I don’t see how it’s used and when, and it demands extra work to understand this.
Meetups, oh meetups
I really like meetups. They build community, nurture the next generation of speakers, and often serve as early channels for new ideas.
A live talk removes a lot of the clickbait noise and tends to offer high-value, authentic content. It’s also more focused than an aggregator, fewer topics, deeper insights.
But meetups have their challenges.
They usually happen after work, which means attendance skews toward people for whom those hours are realistic: not parents of young kids, not those who live far from city centers.
The signal-to-noise ratio can also vary: with only one or two talks per meetup, a weak one can easily make half your evening feel wasted.
And while meetups do have organizers acting as curators, it’s hard to maintain a steady flow of great talks, especially in long-running groups.
So sometimes, the curation defaults to “whatever we can get” instead of “the best we can find.”
Conferences
To me, good conferences, the ones with strong curation, are the best solution to this problem currently.
They happen during work hours, offer a great signal-to-noise ratio, and even if one talk misses, there are plenty more that won’t.
Besides that, as my colleague (ok, my boss) Shota Papiashvili once pointed out to me, you can even learn from the vendor hall. It shows what problems people are trying to solve right now. Sometimes that mostly reflects where the VC money is going, but often it’s a genuine signal:
Maybe that’s a problem you’re also facing, and maybe there’s already a tool for it. It might also validate “it’s not happening only to us”, and that’s also valuable. (Okay, yes, we all go there for the swag mostly. But still.)
How to Make the Most of a Conference
Since conferences are valuable opportunities, it’s worth planning your visit:
Look over the list of talks and workshops in advance, decide where to go, and consider scheduling some breaks (some of us can’t listen to talks nonstop all day).
I like to write down (or tweet) key insights or follow-up topics as I go.
And I try to choose at least one talk in a field I know nothing about, but that sounds intriguing or challenging.
That’s my chance to discover a new unknown unknown.
Getting to a conference
Unfortunately, many companies I know have a “one conference per employee per year” policy.
In my opinion, that’s far too little. (Two per year should be the minimum.)
The usual arguments: cost or lost work time, don’t really hold water in my view, especially compared to developer compensation and the difficulty of hiring.
And even in companies that allow it, many developers don’t take advantage of it, and team leads rarely encourage them to.
That should change.
Conference (and meetups) participation should be part of the conversation between developers and their team leads. We should care about how our developers learn new stuff.
And yes, that’s especially true for the team leads themselves.
To sum up
We, as developers, are constantly busy and overloaded.
But if we don’t want to stagnate, we have to make a deliberate choice to grow and to keep learning new things.
We need to deepen our knowns, expand into known unknowns, and every once in a while, explore our unknown unknowns. And we need to plan the road towards it.
