Programming · by Aoi Ito · 2026-08-27
Which advice about debugging did you eventually ignore with limited time?
I had a disappointing first try, a surprisingly good second try, and then a third attempt that taught me humility. So, naturally, I now have opinions.
Part of me wanted the fancy version with all the tools. The better version was boring: one notebook, one reminder, and a willingness to be clumsy with the prototype for a while
31 sparks · 10 comments
Comments
Aoi Ito · 3 likes
Start by reducing it to the smallest reproducible piece then change one variable at a time. If two options look equal, choose the one that is easier to reverse.
- Write down the exact error and the input that caused it.
- Make a tiny example, then add pieces back slowly.
- Keep the final fix boring and well-named.
Source: mostly hard-won experiance and comparing notes with people who stuck with it
Ethan Brooks · 2 likes
The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. It reminds me of a very specific conversation near the kitchen
Cozy River · 2 likes
I would log the input, the expected output and the actual output first. Once those three are visible, the bug usually stops feeling mysterious. This pairs weirdly well with dumplings
Tanvir Rahman · 1 likes
The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. The low-effort version is probably the keeper
Priya Nair · 0 likes
This is the gentle version of my rant
Aisha Jacobs · 1 likes
Start by reducing it to the smallest reproducible piece, then change one variable at a time. The trap is trying to optimize before you have feedback.
- Write down the exact error and the input that caused it.
- Make a tiny example, then add pieces back slowly.
- Keep the final fix boring and well-named.
That should give you a solid first pass
Mariam Said · 0 likes
This is the kind of disagreement I like