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, 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.