For most of my career, I thought software engineering was primarily about building things.
Choosing the right architecture.
Writing clean code.
Designing scalable systems.
Picking the right framework.
Optimizing performance.
Like many engineers, I believed the difficult part was implementation.
Recently, that belief changed.
Not because I suddenly became a better programmer.
But because I realized I had been asking the wrong first question.
Instead of asking,
"How do we build this?"
I should have been asking,
"Should this be built at all?"
That sounds like a small difference.
It isn't.
It completely changes how you think about engineering.
Engineers Love Solutions
Give engineers a problem and we'll immediately begin designing the solution.
We'll sketch architectures.
Compare frameworks.
Debate databases.
Experiment with AI models.
Think about scalability before we've even validated the need.
It's what we're trained to do.
Building systems is exciting.
But somewhere along the way, many of us become obsessed with solving problems before we've determined whether they're important enough to solve.
That's a dangerous habit.
Technology doesn't create value by existing.
It creates value by solving meaningful problems.
The Question That Changed My Thinking
During a recent hackathon, mentors kept asking questions that had almost nothing to do with technology.
Instead they asked:
Is this problem actually worth solving?
How many people experience it?
How often does it happen?
What does it cost the business today?
How much operational effort does it create?
If you improve this process by just 5%, what changes?
Those questions were surprisingly difficult to answer.
Not because they required technical knowledge.
Because they required understanding the business.
For the first time, I realized that software is only one piece of a much larger equation.
Code Is Becoming Easier
Today, AI can generate:
Even complex implementation tasks are becoming significantly faster.
The cost of writing software is falling.
The availability of software engineers continues to grow.
In many cases, implementation is no longer the primary bottleneck.
The bottleneck is knowing what deserves to be built.
Great Startups Don't Win Because They Write Better Code
History is full of companies that didn't invent new technology. They identified better problems.
They recognized friction that millions of people experienced and built products that removed it.
Technology was the enabler.
Problem selection was the advantage.
The bigger the problem, the bigger the opportunity.
Every Problem Is Not Equal
This is something I wish I had understood earlier.
Two applications may require the same amount of engineering effort.
One might save ten minutes for fifty people each month.
Another might save thirty seconds for ten million people every day.
Technically, they could be equally difficult.
Economically, they're worlds apart.
That's why the first responsibility of an Engineer, especially if you want to build products or startups, isn't writing code.
It's understanding the magnitude of the problem.
Ask questions like:
How many people are affected?
How frequently does it occur?
What is the financial cost?
What is the operational cost?
What is the human cost?
What happens if this problem disappears tomorrow?
Only after those answers become clear should technology enter the conversation.
Engineering Is Becoming More About Judgment Than Coding
I don't believe software engineering is disappearing. Far from it.
Reliable software still requires engineering judgment, careful design, testing, security, maintainability, and countless trade-offs that no prompt can eliminate.
But I do believe the value of engineers is shifting.
As implementation becomes faster, the ability to identify meaningful problems, understand users, evaluate trade-offs, and connect technology to business outcomes becomes increasingly valuable.
The engineer who only knows how to build will always be useful.
The engineer who knows what to build and why will shape products, companies, and industries.
What Changed for Me
I still enjoy building software. I probably always will.
But these days, I find myself spending more time asking questions before opening my editor.
Is this solving a real problem?
Who benefits?
How much value does it create?
Is this the highest-impact use of our time?
Because writing software is no longer the hardest part.
Choosing the right problem might be.
