Programming · by João Pereira · 2026-10-04
Which advice about debugging did you eventually ignore on a budget?
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.
The detail that surprised me was how much my desk changed the outcome. Same plan, different setting, completely different energy.
61 sparks · 9 comments
Comments
Nour Ali · 8 likes
The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. This is where I would ask one more question before choosing.
Sara Ahmed · 4 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.
Come back with what happened; the details will make the next answer better.
Lina Al Harbi · 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 experience and comparing notes with people who stuck with it.
Jack Taylor · 3 likes
Wonderful detail. It makes the whole thing feel real. The low-effort version is probably the keeper. The boring solution is probably the reliable one here.
Laura Gómez · 2 likes
Try making a tiny reproduction with no framework code. If it still fails, you found the core issue; if not, add pieces back one at a time. For me it came down to the first draft.
Ngozi Bello · 0 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.
Source: mostly hard-won experience and comparing notes with people who stuck with it.
Silver Runner · 0 likes
Try making a tiny reproduction with no framework code. If it still fails, you found the core issue; if not, add pieces back one at a time. That is where the boring checklist helps.
Miguel Santos · 0 likes
There is probably a middle ground here. It sounds small, but the prototype matters.
Tola Ibrahim · 0 likes
Try making a tiny reproduction with no framework code. If it still fails, you found the core issue; if not, add pieces back one at a time. For me it came down to the recipe.