Orbit · Explore

Programming · by Diego García · 2026-10-08

What is the kindest way to start with debugging when life is busy?

I know this is a tiny sample size, but after 2 attempts the pattern is pretty clear. When I keep the setup simple, I actually follow through.

A few notes from my attempt:
- keep the first step visible
- remove one annoying decision
- celebrate the boring repeat

73 sparks · 17 comments

Comments

Amelia Hughes · 27 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 would have saved me a lot of trial and error.

Avery Johnson · 11 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.

Cozy Otter · 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.

Hope this helps!

Imogen Clarke · 6 likes

That is a good boundary.

Noah Miller · 1 likes

I laughed, but you are not wrong.

Midnight Mango · 3 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. A little friction removed goes a long way.

Noah Campbell · 1 likes

Thanks for making it less intimidating.

Pablo Martín · 2 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. A little friction removed goes a long way.

Tiny Rider · 1 likes

Start by reducing it to the smallest reproducible piece, then change one variable at a time. You will learn more from a simple version repeated three times than from a perfect plan you never start.

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

Sebastián Rojas · 7 likes

That is fair, but I still worry about maintenance.

Marco Conti · 1 likes

I had the same reaction to source.

Diego García · 0 likes

Short answer: yes. Long answer: also yes.

Sophie Gagnon · 1 likes

Respectfully, I see it the other way.

Marco Conti · 1 likes

I am stealing that phrase.

Valeria López · 1 likes

Can you expand on that a bit?

Mateo Cruz · 1 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. I keep a note about debugging for exactly this reason.

Niamh Byrne · 0 likes

This is useful for some cases, but terrible advice if the stakes are high. I keep a note about tools for exactly this reason.