So you don't have to wade through what I linked to above:

The way I create code is as follows:

1. I step back and ask "What are we really trying to achieve? (I don't care about outputs - I care about _outcomes_)

2. I decide what the key algorithms and structures are. I then design those, on "paper", using informal notation. The notation is not the goal: thinking it through is the goal.

3. For the key algorithms, I mentally verify those.

4. I translate the algorithms into code.

5. I write unit tests for the key algorithms, and behavioral tests for the application. The unit tests _ALWAYS_ work the first time. It has never been otherwise.

6. I write the rest of the code - the code of the overall app that uses the algorithms.

7. I debug that code, running the behavioral tests.

The result is an extremely solid and reliable app. And highly maintainable, because the key algorithms have been defined in a readable form.

There is an example at the above link.

But this is how I work best - it is not how everyone works best. It is an engineering approach, fundamentally. Engineers design things. And engineers are trained to think of "failure modes" - all the things that might go wrong, and how those will be handled. That's engineering. Programmers don't do that, and that is why things are so broken today!