Introduction
For the last few months, I’ve been stuck on what should have been a simple question: What should I learn next? What should be my learning priorities? The problem wasn’t a lack of options. It was too many options.
At first, I thought the answer would come naturally. There are so many things in technology that interest me. I wanted to learn React because frontend has always been a weak point for me. Linux deeply because every serious system runs on top of it. I wanted to explore observability, performance testing, and SRE because I enjoy understanding why systems fail and how to make them reliable. I wanted to improve my use of AI so that it could become a genuine force multiplier rather than just a fancy search engine.
At the same time, I was preparing for interviews. Interviews brought their own set of demands: DSA, High Level Design, databases, Node.js, JavaScript, TypeScript, and distributed systems. Every path seemed valuable. Every path seemed interesting. And that is exactly what turned out to be the problem.
Eventually I realized I wasn’t struggling to choose a technology. I was struggling to identify my biggest capability gap.
Looking back at what I’ve already learnt
When I started reflecting on my career so far, I noticed something important.
I’ve spent years building backend systems on crypto exchanges, healthcare systems, travel platforms, e-commerce products, and large-scale data collection systems. I’ve built APIs, designed databases, deployed applications, worked with cloud infrastructure, and spent countless hours thinking about architecture.
Somewhere along the way, I realized that backend development no longer felt mysterious. I still have a lot to learn, I probably always will. But if someone asks me to build a backend service, I know how to start and how to finish it. That realization became an important clue.
The surprise value of DSA
One thing that completely changed my perspective was Data structures and algorithms (DSA). For years, I viewed it primarily as interview preparation. Something necessary. Something useful. But ultimately separate from real-world engineering.
The more questions I solved, the more I realized I had misunderstood its value. DSA wasn’t making me better at solving interview questions. It was making me better at thinking and improved my ability to decompose problems and identify patterns. It forced me to reason about state, complexity, trade-offs, and edge cases. Problems that once felt overwhelming suddenly started feeling approachable.
For the first time, I felt noticeably more confident in my engineering abilities. Not because I had memorized algorithms, but because my problem solving skills improved.
The question that changed everything
Eventually I stopped asking: “What technology should I learn next?” And started asking: “What capability am I missing?” That one question immediately made things clearer.
When I looked honestly at my strengths and weaknesses, one gap stood out more than any other – frontend. For years, frontend has been my kryptonite. I can build backend services, design APIs, reason about architectures, and deploy systems. But if someone asked me to build a complete product end-to-end from scratch, frontend would be the area where I felt the least comfortable.
Suddenly React stopped being just another technology on a long list. It became the solution to a very specific problem. I want to learn React because it closes a capability gap. It moves me closer to becoming the kind of engineer who can build a complete product end-to-end.
My learning priorities for the next year
Once I started thinking in terms of capability gaps rather than technologies, the answer became obvious. There was one area that consistently limited what I could build on my own, and made me feel underconfident: frontend development.
For the first time in a long time, I have clarity. My primary focus will be DSA and React. DSA because it improves the quality of my thinking. React because it removes my biggest capability gap right now.
Everything else remains interesting. I’ll continue learning about Node.js, JavaScript, TypeScript, architecture, AI, Linux, Performance testing, SRE, and distributed systems whenever opportunities arise. Those interests aren’t disappearing. They’re simply not the bottleneck anymore. For the first time in a while, I don’t feel the need to chase every interesting technology.
I know what I’m optimizing for. I’m optimizing for becoming the kind of engineer who can build an entire product from start to finish with confidence. After that, I’ll decide what the next capability gap is. Maybe it’s Linux. Maybe it’s SRE. Maybe it’s something I haven’t even considered yet. But that’s a problem for future me.
A question for your learning priorities
Most of us decide what to learn based on industry trends, job descriptions, social media, or whatever technology is generating excitement this month. But what if that’s the wrong starting point? A better question might be:
What is your current Kryptonite? What capability would make you dramatically more effective if you developed it?
Your answer might tell you exactly what you should learn next.
Leave a Reply