Frameworks and libraries come and go. Every year there's a new thing you're supposed to learn. It's easy to feel anxious — like you're always behind, always missing something.
The anxiety isn't really about the frameworks. It's about the fear of the unknown. What if I need this and I don't know it? What if the stack changes and I'm left behind?
The way I've learned to deal with that is simple: know your unknowns.
I know how that sounds. If something is unknown, how can you know it? The trick is that "unknown" here doesn't mean "things you've never heard of." It means things you're not deeply familiar with yet — areas you haven't had a chance to work in, or concepts you've only touched in passing. You might not know the details, but you can know that the area exists, what problem it solves, and roughly how it fits into the bigger picture.
The goal isn't to master everything. That's not possible and not practical. The goal is to build a knowledge system — a map of how things connect — so that when you run into something new, you're not starting from zero. You know the underlying logic. You know which fundamentals apply. You can get familiar fast because you already have a place to hang the new information.
Learn the floor, not the furniture
A lot of learning advice tells you to "learn the fundamentals." That's right, but it can feel vague. Here's what I mean in practice.
Networking: Don't chase every HTTP client library or every RPC framework. Learn how TCP/IP works — connections, packets, what happens when you send a request. Once you understand that, any library is just like different APIs of doing the same thing. You'll read the docs and think "oh, it's doing X under the hood" instead of "I have no idea what this is."
Databases: You don't need to know every ORM or every NoSQL flavor. But if you understand indexes, transactions, and why some queries are slow, you can pick up any database or query language much faster. The concepts transfer.
Message queues: Kafka, RabbitMQ, NAT — they all solve the same kind of problem: getting work from one place to another without the sender and receiver being tied together. Learn the ideas: producers and consumers, ordering guarantees, at-least-once vs at-most-once delivery, what happens when the consumer is slow. Once you get that, picking up a new queue system is mostly learning its API and its particular tradeoffs, not learning a new paradigm.
The pattern is the same: learn the layer underneath. The "floor" changes slowly. The "furniture" — the specific frameworks and libraries — gets replaced all the time. If you know the floor, you're never lost when someone rearranges the furniture.
You don't need to know everything well
You need one or two areas where you're genuinely deep. That's your home base. The rest is breadth.
Breadth means: you know the area exists, you know the main ideas, and you know you can go deep when you need to. You don't have to be an expert in distributed systems, compilers, and ML all at once. You just need to know enough to recognize when a problem belongs in one of those buckets, and enough to learn quickly when the time comes.
That's what "know your unknowns" means. You have a map. The map has some blank spots — those are your unknowns. But you know they're there. You know roughly what kind of thing goes in that spot. So when you land in one of those spots, you're not lost. You're filling in a part of the map you always knew was there.
Frameworks will keep changing. The anxiety doesn't have to. Build the map. Learn the floor. The rest is just details you can pick up when you need them.