# The Biggest Thing I Learned at a Hackathon Had Nothing to Do with AI

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.

* * *

![Illustrates that engineers naturally jump to solutions before understanding users.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/a64063aa-789d-4a25-8351-38a55d1cdf3d.png align="center")

## Engineers Love Solutions

Give engineers a problem and we'll immediately begin designing the solution.

1.  We'll sketch architectures.
    
2.  Compare frameworks.
    
3.  Debate databases.
    
4.  Experiment with AI models.
    
5.  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.

* * *

![Represents the shift from engineering questions to business questions.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/b6bafcd6-da53-4a65-9a09-eaadd7a61d40.png align="center")

## 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.**

* * *

![An AI assistant rapidly generating application code across multiple monitors while a software engineer watches. Not claiming AI replaces engineers. Instead, AI accelerating implementation with Software Engineer.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/83626290-33b1-4fcd-9e1f-4ec4b8084618.png align="center")

## Code Is Becoming Easier

Today, AI can generate:

*   Boilerplate code.
    
*   Scaffold applications.
    
*   Write APIs.
    
*   Generate tests.
    
*   Explain unfamiliar frameworks.
    

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.

* * *

![Problem selection > Better tools. Three people digging for gold in a mountain. Two are polishing expensive tools while one person studies a map pointing toward the richest vein of gold.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/30e4e653-fd30-43e4-820a-6ce6dc988d1e.png align="center")

## 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.**

*   [Uber](https://www.uber.com/in/en/) didn't invent GPS.
    
*   [Stripe](https://stripe.com/) didn't invent online payments.
    
*   [Airbnb](https://www.airbnb.com/) didn't invent booking systems.
    

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.

* * *

![A balance scale comparing two software projects. One side shows a complex application serving only a handful of users.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/c2cab099-003c-42a1-b9e2-f0cbe3eb41e1.png align="center")

## 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.

* * *

![A software engineer examining multiple transparent holographic layers including customer journey maps, business metrics, architecture diagrams, AI workflows, operational costs, and user feedback before writing a single line of code.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/e8a8cede-eaed-4bef-b312-e9bfcc2d9556.png align="center")

## 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.

* * *

![An engineer closing a laptop at sunset while looking over a city skyline. Floating around him are transparent questions instead of code: customer icons, financial graphs, workflow arrows, clock symbols, and impact diagrams representing thoughtful problem solving.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/e381f4d9-b3f9-4939-8899-0aca6b9bb614.png align="center")

## 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.**