@cosy_skog I've been a professional software engineer since 2001, in the sense that I actually get paid legitimately by large corporations to solve a variety of problems.
The answer is, in my experience, you don't.
All you can really do is trust in your development processes, whichever one you choose to invest time in learning. For me, it was #TestDrivenDevelopment and #ExtremeProgramming.
I often start by creating a crude model of a candidate solution, fully knowing ahead of time that that solution is going to be wrong. But, it starts out as being "good enough" to solve some of the problem at hand. Over time, I just hack on it and refine it, adding tests here and there to verify my understanding and guide my development process. And, yes, there are times, when I go down a wrong path, learn something new about how to do it better, and I end up having to rewrite both tests and production code. It's part of the process. It's frustrating. I often have to walk away from the computer for a day or two to cool off from it. But, it happens, and the end result is usually better for it.
But the process is key -- basically, don't give up, keep chipping away at the problem until you have a solution you are satisfied with, and maybe then move on. Software is rarely ever "done". But, for a given problem, it can be "done enough."
That said, here's a few things I found that works well for me:
Consider designing a solution either from the top-level down or from the inside-out. Never design from the bottom up unless you have sound understanding of the problem domain and customer requirements.
Consider implementing a solution from the bottom-up or from inside-out. Once you have a design (which is really just a "here is how I plan on writing the software components and how they fit together"), it's much easier to lay a working foundation so that you can come to trust in it axiomatically. It's easier to reason about your code if the lower-level foundation has already been proven to your satisfaction.
Try to avoid top-down implementations. These can work (and we have working examples of complex systems written this way, such as the Oberon System and many compilers in the Pascal/Modula family); however, it can also lead to overly complicated implementations. You might find that a lower-level structure doesn't quite fit into the "user interface" (so to speak) of the module you're trying to write, and instead of feeling like you're free to change that interface, you often add adapters or compatibility layers to act as bridges between the high- and the lower-level code. Working bottom up helps eliminate those excess pieces of code.
As you can imagine, working with test-driven development allows you to work "inside-out" which is a valid approach for either situation. You'll often find the quality of the code to sit somewhere in between top-down and bottom-up; some complexities will arise (adapters/shims to facilitate interaction between modules or to support better testing), but it'll not be anywhere near as bad as a purely top-down implementation or a bottom-up design.
Hoping this helps out, and I wish you luck on your learning journey.
