I start by using it

To know whether something is broken, you have to know how it works when it isn’t broken, and why it works that way.

I think that comes from my time as a mechanic. It’s an approach I’ve carried from maintenance work in the Army into software.

My first goal is to learn enough to fix the bug or implement the feature I’m working on. I want to get to a point where what I’ve learned is usable. There’s always more I can study after that.

I use it before I dig into it

When I’m learning a system, I usually start by actually using it. How is it supposed to work?

Then I ask why. Why is it supposed to work this way?

Finally, I dig into what makes it behave that way. I’ll branch into the integrations, too, to understand why they’re involved and how they work.

I want to understand the behavior I’m seeing and what’s behind it. I’ll keep following those questions into the system.

Can I explain it in my own words?

For me to believe I understand something, I need to be able to explain it in my own words.

I might be explaining it to a friend, talking it through with a coworker, or writing it down in my own notes. If I can’t explain a part of it, I know where I need to dig deeper.

That gives me a specific gap to work on.

Following the gap

I’ll read up on the subject, then use it again.

If I need to, I’ll add debug breakpoints so I can follow what’s happening as the code runs. I’ll reach out to someone with expertise in that part of the system, if there’s someone available. I’ll watch videos, too.

Then I come back to the same check: can I explain it in my own words? The part I still can’t explain tells me where to keep digging.

Making the understanding useful

For that first round, I focus on understanding the behavior I need to change well enough to fix the bug or build the feature. That gives the investigation a practical goal.

Once I can use what I’ve learned, I can keep studying the parts I find interesting. Bugs and failures teach me more, too. My understanding keeps developing as I work with the system.

When I’m developing something new, I take an engineering approach: ask questions and look for failure points. Learning how something works also means thinking about where it could go wrong.

I want to understand it well enough to act, then keep learning from what happens.