I Blamed My Phone for a Problem My Computer Was Causing

For weeks I had a theory: my phone connection was dropping, and that was killing my work. Every time it happened I nodded along to my own explanation and asked for a fix aimed at the connection.

The fix I asked for was not the fix I needed. The thing killing my work was not the connection at all. It was restarts I was triggering myself, on my own computer.

What the record actually said

Instead of accepting my theory, the system’s own record got pulled and lined up against what had actually happened. Two things came out of that immediately.

Work that had been running overnight with nobody even connected to it had survived the whole night untouched. That ruled out the connection as a cause outright. If a dropped connection were the killer, overnight work with nothing attached to it should have died too. It didn’t.

What actually killed things were restarts I had done myself, of the computer and of the program hosting the work. Everything tied to that program died at the exact same moment every time, which is what it looks like when a shared parent goes down, not what a scattered series of random crashes looks like.

A quiet status is not the same as a dead one

There was a second mistake sitting on top of the first one. I had also written off several pieces of work as failed, because they had gone quiet and stopped producing new output. Quiet is not the same as dead. When checked properly, all of them were still running fine. They were just waiting, one of them literally paused mid-task waiting on me to say the word to continue.

That misreading almost sent me toward the wrong fix a second time. Because I believed the connection was the problem, the first idea on the table was a tool built specifically to survive dropped connections. It would have solved a problem I did not actually have.

The real fix, once the real cause was known

Once the actual cause was confirmed, the fix was small and specific: a way to move an already-running piece of work over to my phone without losing its history, so that if my computer did need a restart, getting back to where I was cost one request instead of a full reconstruction. That fix only made sense once the connection theory had been ruled out. Building it around the wrong cause would have solved nothing.

The rule I run on now

Before I call something dead, I check whether it is actually still running, not just whether it has gone quiet. And before I commit to a fix, I confirm what the record actually says caused the problem, rather than running with the first explanation that felt familiar.

The restarts were mine the whole time. I would never have found that by staring harder at the connection.

dxdev LESSON · paste into your AI coding agent
LESSON: Confirm the cause from the record before you commit to a fix
SOURCE: dxdev.com/blog/2026-07-07_i-blamed-the-wrong-thing
WHAT HAPPENED: Work kept getting interrupted, and the assumption was a flaky remote connection. The system's own event log told a different story: the work was surviving disconnections just fine, and what was actually ending it was a restart the person doing the blaming had triggered themselves. A second wrong assumption, that some of the work had crashed, turned out to be a misreading of an idle status as a dead one.
THE RULE: Before choosing a repair, confirm the actual cause from the system's own record, not from the most available assumption. A first guess that sounds plausible is not the same as a cause that is confirmed.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any incident, outage, or recurring interruption where a fix was proposed or built based on an assumed cause that was never confirmed against a log or record.
  2. Any status check that infers something is finished or dead from a signal that only proves it went quiet, rather than checking whether it is actually still running.
  3. Any repeated problem where the same explanation keeps getting reached for out of habit, without re-checking whether the record still supports it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.