Interesting how seemingly-at-odds this is from another highly upvoted trick: the one that begins "Understand the problem and solution before coding." Hard to find that balance sometimes between "just dive right in" and perfectionism.
For me this means walking through use-cases of an idea "on paper" while resisting the temptation to actually design the solution. Once you've defined the verbs/nouns of the system you're much better prepared to "dive in" and build something. That, in turn, will uncover things your paper system forgot or burst your illusions about certain use-cases causing you to rethink them. Rinse, repeat.
I've been the "overthink it" person, the person to spend way too much time on preparation only to start the implementation and realise one or many of the reasonable assumptions I've made are wrong and then have those affect everything else. I could have done a new on-paper solution for every single fork like that in the preparation phase (greatly extending it); or, I could have learned enough to _get started_ and come back to the drawing board to re-learn each time these (before: assumptions) are met.
It's a careful balance of preparedness and real-world discovery. Neither gives a complete picture without the other. Neither is even possible without the other.
Spending too long preparing is as bad as spending too little time. Too long and you account for possibilities that may not even exist, things you cannot know until you enter the system. Too little time and you're a bull in a china shop.