Orbit · Explore

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, diffrent 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 experiance 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 probly 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