How a non-coder debugs: read, don't reproduce

I've never reproduced some of Jiva's hardest bugs. I found them by reading the code against the exact symptom until the failure became inevitable on paper.

When a user reports a bug in software I cannot really write myself, I cannot debug it the way an engineer would — set up their exact conditions, reproduce it, step through it. Several of Jiva's hardest bugs I have never reproduced at all. I found them another way: by reading the code carefully and reasoning about what it must do, until the failure became inevitable on paper.

The two download models that reported failure, the app that could not be reopened — I did not recreate either. I read the relevant code with the user's exact symptom in mind and asked, in effect, what would have to be true inside for this specific thing to happen. For the failed downloads, re-reading showed that two output streams shared one pipe, so a status marker could get glued to the tail of a progress bar and silently dropped — which exactly matched the reported signature. Note that the primary tool here is not a debugger, rather a precise symptom plus a careful read: the report tells you what the world looked like from outside, and the code tells you which internal state produces that view.

This is slower in some ways, and it demands that you actually understand the code the AI wrote, which is its own discipline. But it works, and for a bug you cannot reproduce, it may be the only thing that does.

The general lesson is that reproduction is one path to a bug, not the only one. A specific enough symptom, read against the code with genuine attention, often pins the cause more reliably than trying to recreate conditions you do not fully control. It also forces the thing I most need as a non-engineer: to understand, not just run, what I am shipping.

More soon.