As a senior (of sorts), even though I don't quite rush to code, I often find myself starting to code something 'naively', while my understanding is lacking (typically in a tangled, inconsistent and poorly documented codebase). But what probably sets me apart from juniors is how I handle getting stuck, or rather what it means for me to try to "fix things". I spend time thinking about what I've discovered that has gotten me stuck, what I must take into account, and how I should alter my approach (or refactor the existing code to be more accommodating).

Sometimes I manage to formulate ideas apriori that reduce the frequency of my getting stuck, and/or the extent to which I need to backtrack. But - not always.

Have you ever heard of the V model (https://en.wikipedia.org/wiki/V-model) ?

Long story short: it does not work, because the act of coding adds new valuable inputs that alters the (original) design.

One might say "you just have to know", which is an equivalent to "you just have to figure out the future", "you just have to be perfect" and other non-sense (which does explain why V cycle does not work, high inefficient, low quality outcome, bad method)