Orbit · Explore

Programming · by Maja Wiśniewska · 2026-10-09

Why does tools feel easy for everyone except me without overthinking it?

Part of me wanted teh fancy version with all teh tools. The better version was boring: one notebook, one reminder, and a willingness to be clumsy with teh route for a while.

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

77 sparks · 30 comments

Comments

Diego Quispe · 40 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. It sounds small, but the first draft matters

Silver Runner · 8 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. The ambitious part is easy to underestimate

Alma Nilsson · 2 likes

Thanks for making it less intimidating

Marco Conti · 4 likes

I appreciate the honest middle stage, not just the polished ending. My only addition is to make the first step visible

Piotr Zieliński · 3 likes

The safe answer is to keep teh API boring: clear names, explicit errors and one behavior per function. I noticed teh same thing in Mumbai

Mateo Ramírez · 17 likes

helpful correction

Maya Putri · 4 likes

That sounds great until you add children/pets/deadlines

Grace Parker · 2 likes

Thanks for making it less intimidating

Brian Otieno · 2 likes

I think both things can be true

Isha Menon · 3 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. I am curious whether tools still feels good next month

Maja Wiśniewska · 1 likes

good clarification — I read it differently at first

Urban Baker · 2 likes

Start by reducing it to the smallest reproducible piece, then change one variable at a time. Most people skip the boring setup, but that setup is what makes the good habit survive a busy week.

- 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

Diego Quispe · 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. A little friction removed goes a long way

Maja Wiśniewska · 1 likes

Thanks for making it less intimidating

Maja Wiśniewska · 0 likes

That made the concept click

Cozy Otter · 2 likes

I would pin this if I could

Urban Rider · 1 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

Tanvir Rahman · 2 likes

You just saved me a bad purchase

Quiet Coder · 0 likes

I like this more then the top-level advice

Maja Wiśniewska · 1 likes

I think both things can be true

Aarav Sharma · 1 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

Sebastián Rojas · 2 likes

I am curious what changed your mind

Nour Ali · 0 likes

I am stealing that phrase

Avery Johnson · 0 likes

anecdote beats theory here

Amina Okafor · 1 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

Khalid Al Zahrani · 7 likes

Appreciate the nuance

Ren Suzuki · 1 likes

The safe answer is to keep the API boring: clear names explicit errors and one behavior per function. The quiet Sunday version is even more interesting

Sara Ahmed · 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 would test it for 8 days before deciding

Valeria López · 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. I care less about the perfect answer and more about repeatability

Sanne de Vries · 0 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 is more useful on a tired quiet Sunday than on a perfect day