Why I stopped thinking about code first — and started thinking about problems

There's a moment in most engineers' careers where something shifts. You stop asking "how do I build this?" and start asking "should we build this at all?"

For me, that moment came after delivering a feature that took three weeks to build — and watching it get used by exactly two people before being quietly removed from the product.²

The code was clean. The tests passed. The CI/CD pipeline was green. And none of that mattered.

What nobody teaches you in bootcamp

Technical skills get you hired. But they don't make you valuable — at least not in the way most engineers think. What makes you valuable is understanding the impact of what you build.

I spent three years as a Product Owner before moving fully into engineering. That experience changed how I read a ticket, how I ask questions in planning, and how I push back when something doesn't make sense.

A practical shift

Before opening my editor, I now ask three questions: what problem are we actually solving, how will we know it worked, and what's the simplest version that proves the idea?

// Before: solving the stated requirement
public async Task SendWeeklyReport(User user) {
  // 200 lines nobody reads
}

// After: solving the actual problem
public async Task NotifyUserOfRelevantChange(
  User user, string changeContext) {
  // Does one thing. Triggered by real behaviour.
}

Software is just the medium. What you're really building is outcomes — for users, for teams, for the business. The sooner that becomes instinct, the better engineer you become.¹