Debugging Lessons from a 3-Year-Old

My son doesn't know when to stop asking "Why?"

Why is the sky blue? Because of how light scatters. Why does light scatter? Because of particles in the atmosphere. Why are there particles? And so on, until we've arrived at the fundamental laws of physics and I've run out of answers.

It's exhausting. It's also the best debugging strategy I know.

The Symptom Trap

Early in my career I was building a web app that was going to live primarily on mobile. It looked great. Then I tested it on an iPhone.

The fonts were broken. Not catastrophically — just wrong enough to matter. My first instinct was to reach for a CSS fix. I tried a few. None of them stuck.

Here's where most of us go wrong: we treat the symptom until something seems to work, declare victory, and move on. I almost did exactly that.

Instead I got an old iPhone, started digging, and asked the question I should have asked first: Why is this broken on Apple devices?

That one "why" pulled a thread that unraveled into a surprisingly deep rabbit hole — Safari vs. Chrome rendering differences, the quirks of WebKit, how progressive web apps behave differently across platforms, and eventually a serious reckoning with whether a web app was even the right tool for what I was building. I came out the other side with a much clearer picture of React Native versus mobile web, and a healthier skepticism toward quick CSS patches.

None of that happens if I stop at the first fix that looks close enough.

The Toddler Method

There's a formal version of this called the 5 Whys — an 8D staple, useful in teams, useful on paper. But for most solo builders, the structure matters less than the habit.

Ask why. Find an answer. Ask why again.

The real magic isn't in counting to five. It's that once you start pulling on a thread — once you've got a real question with a real answer that spawns another real question — curiosity takes over. You stop counting. You just keep following where the information leads.

Good engineers are curious enough that the method becomes invisible. They're not running a protocol. They're just genuinely interested in why the blue block won't stay on the red block.

A few other things my son has right:

Try it, see what happens, try again. He doesn't catastrophize a failed hypothesis. He just runs the next experiment.

Know when to take a break. Some of his best "why" sessions happen after a snack and some time outside. Turns out stepping away still works in software, too.

The Real Lesson

The CSS wasn't the problem. The CSS was what I could see. The problem was that I had built something for a platform I didn't fully understand yet.

You can't fix what you don't understand. And you can't understand it until you've asked enough whys to reach something true.

Your three-year-old figured that out before you did.