"Not There" and "Didn't Find It": I Got It Wrong Twice

I built something that picks one writable topic for me each day out of a pile of stored material. The logic is simple: search once, proceed if there are results, skip the day if there are none.

Last week that logic failed twice — once in the code, once when it made the judgment for me. Both were the same hole: treating "I did not find it this time" as "it does not exist at all." This mistake is not limited to my tool. When job applications go unanswered or outreach gets no reply, plenty of people reason the same way.

First, the code.

The tool fetches data from a backend, normally returning a list. Contents in the list, keep processing. Empty list, meaning the query ran and there genuinely is nothing — also a normal result.

The problem was how I tested for empty. Taking the lazy route, I used a very common shortcut: if what came back looked empty in any way, treat it as no result, treat it as a failure, throw it away and retry.

Empty can be a valid answer, not an error signal. Queried and found nothing, versus never got a result at all, are two different things. That line of code merged them, so a flow that should have proceeded normally judged itself broken and stalled.

The fix was easy — a more precise check. I assumed that was the end of it.

The tool has another job: pick something writable from the pile each day. Same approach — search once, use it if found, skip if not.

A few days ago it told me there was nothing usable today and recommended skipping. The reasoning looked sound, so I followed it, and recorded "nothing available today" as the day's conclusion.

A day later I went through the newest entries in the backend myself and found that was simply untrue — new material was sitting right there. The search terms we used just did not match the wording in the source. Not finding it does not mean it is absent.

Exactly the same logic hole as the code: drawing the "nothing here" conclusion after one search saves a step and bets that search is always reliable. The cost was nearly writing off usable material as a skip, and nearly enshrining that flawed method as the rule.

This is not a problem with the search tool. The judgment standard itself had a hole — equating "I did not find it this once" with "it does not exist." Humans and code committed the same laziness.

This does not mean verifying ten times over from now on.

The distinction: failing to find it from several angles probably means it is genuinely absent; concluding after one search only proves you did not search well. The step between one check and cross-verification is the entire distance between "I thought there was nothing" and "there is nothing."

I have already changed the rule: first walk the newest entries by time to catch anything missed, then use search to supplement and rank. One fruitless query does not count.

With that flow fixed, those two mistakes were worth it — they put an easily ignored thing in plain sight: a judgment shortcut usually costs far more than the effort it saves.

Next time the thought "this is hopeless" or "this path is blocked" shows up, ask yourself first: did several approaches genuinely fail, or did one attempt decide it? Between those two may sit an entire opportunity you crossed out.