Why We Need to Stop Calling Everything a Problem That Needs Solving

I want to push back on a pervasive assumption that has become our default operating mode — the belief that any observation about an imperfect situation is fundamentally a problem demanding a solution. This worldview treats existence as something to be optimized rather than experienced, and in doing so it strips away vast categories of human activity from their proper place. The phrase "problem solving" implies there's a fix, but some things are simply conditions to be lived with — not solved. Your existential dread isn't broken; you don't have an anxiety disorder that needs medication; your relationship is flawed in the same way all long-term human connections are. When we label these as problems requiring solutions we commit ourselves to a frantic engineering ethos that can't actually deliver what it promises. We optimize our lives into sterile efficiency while losing the capacity for appreciation, which requires acknowledging imperfection rather than eliminating it. I'm not saying everything is fine — far from it. But let's be honest about what's solvable and what isn't before we keep trying to re-engineer reality as if it were buggy software.

The impulse to frame everything as a problem is often a category error disguised as productivity. There's a useful distinction between:

Problems: objective gaps between current and desired states with actionable paths (broken build, unresponsive server, actual bug). Solve these fast.

Friction: suboptimal flows that don't prevent progress but slow it down (annoying CI config, verbose logs, toolchain quirks). Don't solve these until they become problems.

Preferences: subjective complaints about how things work (I don't like this UI pattern, I wish the CLI flag was named differently). These aren't problems — they're opinions. Shipping them is a luxury that costs other people time.

The error compound: you spend 20% of your engineering capacity solving preferences and friction as if they were problems. By the time a real problem arrives (database regression, race condition), your system is brittle because it was optimized for what engineers want rather than what the

This. The optimization mindset has become pathologically applied to things that aren't broken.

The impulse to solve everything comes from how we're trained — every issue at work gets framed as a problem with a root cause and a solution. But some things are just features of being human or operating in complexity, and trying to "fix" them creates more problems than it resolves.

A few specific categories where the solve-everything instinct backfires:

1. Systemic constraints. If your team is underfunded and overworked, that's a constraint, not a problem you can optimize away with better tooling or processes. Trying to solve it at the individual level creates burnout instead of progress.

2. Emergent complexity. Distributed systems fail in ways no one predicted because interaction effects are exponentially harder to model than component failures. You don't "solve" distributed system failure; you design for graceful degradation and recovery. The goal shifts from prevention to resilience.

3. Trade-off surfaces. Almost every technical decision has a cost on another dimension — latency vs

The premise itself is circular and therefore uninteresting. "Need solving" implies a problem exists, which means we've already decided something requires intervention. The thread conflates three distinct categories: (1) actual problems — functional failure where the system doesn't do what it was built to do; (2) inconveniences — frictions that are survivable but annoying; and (3) values-based preferences disguised as deficits.

The problem isn't that we call everything a "problem." The problem is that our vocabulary has collapsed, so when someone says they have a problem with the urban design of their neighborhood, they can't tell you whether it's an engineering failure or just their personal aesthetic preference, and you don't know either.

If I say my car makes a rattling sound, that's a real problem — something is objectively broken. If I say I have a problem with the speed of modern software development, that's a value judgment about acceptable trade-offs. Conflating these lets people wield "problem" as rhetorical force rather than descriptive tool.

So don't stop calling things problems. Start being honest about what kind of problem you actually mean. The current ambiguity is more dangerous