I Stopped Chasing Frameworks. I Started Chasing Problems.
- #engineering
- #career
- #product
- #learning
JavaScript gave me enough reasons to learn a new framework every year.
Angular.
React.
Vue.
Svelte.
Solid.
Every few months, there was a new framework promising to solve all the problems the previous one couldn't.
And honestly?
I loved it.
Early in my career, I believed becoming a better software engineer meant always staying ahead of the next trend. Whenever a new framework was released, I wanted to be among the first to try it.
It felt like growth.
Then something unexpected happened.
The more products I built, the less anyone cared about the framework behind them.
Nobody has ever opened an application and said,
"Wow... this must be built with React."
Instead, they say things like:
"This is really easy to use."
Or...
"I found what I needed in seconds."
That realization completely changed the way I learn.
Today, I still enjoy exploring new technologies.
I just don't chase them anymore.
Instead, I spend much more time understanding the people using the software.
I thought technology was the biggest competitive advantage
When I started my career, weekends usually looked the same.
A new JavaScript framework was trending.
Tech YouTubers were calling it the future.
Developers on X and Reddit were debating whether every existing framework was now obsolete.
So naturally...
I opened my laptop.
Created another demo project.
Built another Todo application.
Learned another syntax.
And felt incredibly productive.
Looking back, I don't regret any of it.
Those experiments helped me understand different programming patterns and made me more adaptable as an engineer.
But after working on enough real-world products, I noticed something interesting.
Projects almost never failed because we picked the wrong framework.
The problems were never technical
Projects struggled because:
- We misunderstood the user's problem.
- Requirements changed halfway through development.
- Features became more complicated than necessary.
- Teams spent weeks building functionality that nobody actually used.
Not once did I hear someone say,
"The project failed because we chose React instead of Vue."
The framework wasn't the bottleneck.
Understanding people was.
That realization quietly changed what I chose to learn next.
Customers don't care what stove the chef uses
Imagine walking into your favorite momo restaurant.
The waiter proudly says,
"Today's momo was prepared using the newest commercial gas stove with AI-powered temperature control."
You'd probably smile.
Then ask the only question that actually matters.
"Is the momo good?"
Nobody recommends a restaurant because of the stove.
They recommend it because the food consistently tastes great.
Software works exactly the same way.
Users don't care whether your application was built with React, Vue, Angular, or whatever framework becomes popular next year.
They care whether they can accomplish what they came to do.
Frameworks are simply the tools inside the kitchen.
The product is the meal.
As developers, we sometimes become so fascinated with the kitchen that we forget someone is waiting to eat.
AI reinforced a lesson I was already learning
The rise of AI made this even more obvious.
Today, tools like Cursor, Claude, and ChatGPT can generate components, APIs, tests, and even entire application screens surprisingly well.
Writing code is becoming easier.
Understanding users isn't.
In fact, I think AI has made problem-solving even more valuable.
Imagine hiring the fastest construction worker in the world.
They can build a house twice as fast as anyone else.
Sounds amazing.
Until you hand them the wrong blueprint.
Now you've built the wrong house...
Twice as fast.
That is exactly how AI works.
Give it clear requirements and it becomes an incredible engineering partner.
Give it vague requirements and it will confidently build the wrong solution at lightning speed.
Speed has never solved poor direction.
It only gets you there faster.
What I spend my time learning today
These days, my curiosity looks very different.
Instead of asking,
"Which framework should I learn next?"
I find myself asking:
- Why are users abandoning this screen?
- What problem are we actually trying to solve?
- Is this feature even necessary?
- Can this experience be simpler?
- What would make someone's day easier?
Ironically, learning about product thinking, communication, psychology, and user behavior has improved my engineering skills more than many of the frameworks I once rushed to learn.
The better I understand the problem...
The simpler the code becomes.
Frameworks still matter
This isn't an argument against learning new technologies.
Frameworks matter.
Libraries matter.
Good engineering practices matter.
I still enjoy exploring new releases and understanding how the ecosystem evolves.
The difference is that they are no longer the destination.
They're just tools.
A chef still needs quality knives.
But nobody visits the restaurant because of the knives.
They come back because of the experience.
The same is true for software.
Final thoughts
If I could give one piece of advice to my younger self, it would be this:
Keep learning new technologies.
But don't let technology become the only thing you learn.
The engineers I admire most aren't successful because they know every framework.
They're successful because they understand people.
They ask better questions.
They simplify complexity.
They solve the right problems.
And interestingly, those skills have helped me build far better software than constantly chasing the next JavaScript trend ever did.
Because at the end of the day, users will remember how your product made them feel.
They'll never remember the framework you used to build it.