- Engineering
- Product Thinking
- Career Growth
- Software Development
Solving the Right Problem Matters More Than Solving It Perfectly
One of the biggest shifts in my career has been learning that good engineering isn't just about building things well. It's about making sure you're building the right thing in the first place.
The shift
For a long time, I thought becoming a better engineer mostly meant getting better at building things.
Better architecture. Cleaner code. Fewer edge cases. Better performance.
Those things still matter.
But after working on real products, I started noticing a different problem.
Sometimes we were spending a lot of time making something better without stopping to ask whether it was the thing that needed to be better in the first place.
That changed how I think about engineering.
Building the wrong thing really well
There is a certain satisfaction in solving a difficult technical problem.
You find an elegant approach. You simplify the architecture. You remove bottlenecks. You handle edge cases nobody thought about.
And then you realize that users don't really care.
Not because the work was bad.
Because the problem wasn't important enough.
A perfectly engineered solution to the wrong problem is still the wrong solution.
That was a lesson I had to learn through experience.
The question before the code
Earlier in my career, my first question was usually:
"How should we build this?"
Now I try to start somewhere else:
"What are we actually trying to solve?"
That small change in the question has a surprisingly large impact.
It forces you to understand who has the problem, why it matters, how often it happens, and what happens if you don't solve it.
Sometimes the answer is to build the feature.
Sometimes it's to build a much simpler version.
Sometimes it's to change the approach entirely.
And sometimes the answer is not to build it at all.
Experience changes what "good engineering" means
As an engineer, it's natural to optimize for things you can directly control.
Code quality is measurable.
Performance is measurable.
Test coverage is measurable.
Architecture can be discussed and reviewed.
But product value is harder to measure from inside the codebase.
That's why it's easy to over-index on technical quality.
A technically impressive solution can feel like progress even when it doesn't move the product forward.
Good engineering isn't about ignoring technical quality.
It's about putting technical quality in the right context.
The best architecture for a problem that doesn't matter is still a bad investment.
Simplicity is often a product decision
I've also become much more comfortable with simple solutions.
Not every problem needs a sophisticated system.
Not every feature needs to be highly configurable.
Not every edge case needs to be handled on day one.
Sometimes the best solution is the one that gets a useful result in front of the user quickly, teaches us something, and gives us a better understanding of what to build next.
That's not an excuse for poor engineering.
It's a recognition that engineering is part of a larger process.
We are not writing code for its own sake.
We are trying to create something useful.
Learning to say no
One of the hardest parts of building products is deciding what not to build.
There will always be another feature.
Another improvement.
Another refactor.
Another optimization.
The question isn't whether we can build it.
We probably can.
The question is whether it deserves the time, complexity, and attention it will consume.
I've found that saying "not yet" can sometimes be a better engineering decision than saying "let's build it."
The mindset I try to carry forward
I still care deeply about building things well.
I still want systems to be reliable, maintainable, and thoughtfully designed.
But I try not to confuse quality of execution with importance of the work.
Before asking how to build something, I want to understand why it should exist.
Before optimizing a solution, I want to know whether the solution is solving the problem that actually matters.
And before adding complexity, I want to know what value that complexity creates.
The biggest career shift for me wasn't learning another technology or framework.
It was learning to pause before building.
To understand the problem.
To question the assumption.
And then, once I'm confident it's the right problem, to build it well.
Because solving the right problem reasonably well is usually more valuable than solving the wrong problem perfectly.