How I approach a problem before writing a single line of code

The small habits I use to slow down, clarify the problem, and avoid solving the wrong thing too early.

I try to delay implementation just long enough to understand what would make the fix unnecessary.

That usually means asking a few plain questions first.

What is actually broken?

Who is feeling the pain?

What changed?

What constraint is real, and what constraint is just inherited?

This sounds simple, but it changes the work. You stop reaching for the first plausible answer and start mapping the shape of the problem. Often the first version of the task is too narrow, or it confuses the symptom for the cause.

I like to get to a point where I can explain the issue in one calm sentence. If I cannot do that yet, I probably do not understand it well enough to code the fix with confidence.

That pause saves time. It also makes the eventual solution much cleaner.