This started with a joke I saw on LinkedIn.
I was thinking about a “sorting algorithm” in O(n) that works like this:
Walk the list once.
If the next number is bigger than the last one you kept, keep it.
If not, drop it.
At the end you return the list of numbers you kept. It’s sorted. You “sorted in O(n)”… by throwing away anything that didn’t fit the story.
As a real sorting algorithm, this is cheating. But as a metaphor, it’s actually close to how good engineers think:
Sometimes the right move is not to solve the original problem, but to change the problem definition to match what really matters.
The trick is doing this on purpose and in the open, not as a hidden shortcut.
When to Change the Problem
In real projects, redefining the “naive” requirement can save months of work.
- Sorting vs. Finding the Latest: Instead of sorting a massive dataset just to find the most recent item, simply query for the max value. You change “sort everything” to “give me the winner.”
- Perfect Data vs. Clear Decisions: When systems disagree (like conflicting client addresses), don’t try to “fix” history. Just define a clear rule: “Latest update wins.”
- Future-Proofing vs. Shipping: Instead of building a permission system for every possible future scenario, build exactly what’s needed for today’s scopes.
From “Solver” to “Shaper”
This is a key shift from mid-level to senior engineering:
- Mid-level: “Give me a clear problem and I’ll solve it.”
- Senior: “I will help shape the problem so it’s worth solving.”
The O(n) sort is funny because it’s obvious cheating. But in engineering, trading “perfect correctness” for “useful, shippable value” isn’t cheating—it’s impact.
The key is to do it explicitly. Say out loud what you are giving up (e.g., “We won’t support historical sort”) to gain what you actually need (e.g., “Instant results”). That’s not moving the goalposts; that’s making sure you’re playing the right game.