If you are asking how to improve the logic of your programming, I would redirect towards Refactoring.
If you are asking about how to improve your approach to encountering new problems, I’ll try to give some general advice.
I always start by picking up pen and paper. On that I phrase out the problem the way I understood it. Depending on the problem, I either write the story (the back-end receives data from a database, which it morphs into business objects, prepares it for transfer and opens an interface), draw diagrams or use post-its.
Then I look at the sentences, post-its or classes I’ve drawn. Do they make sense to me? Can I write/draw the problem more specifically? What happens if I change the way I organize the post-its/topics? I add and change whatever I come up with, and then do it all over again with my new insights.
Most of the time, my intuition takes over, and I just repeat the steps until I think I know what I have to do in the program - and roll with it.
Methodologically speaking: I’m working through different phases.
Phase 1: Analysis
Which is sketching the problem as I understood it in it’s context (read: input / output; what goes in, what goes out, the like). Usually a lot of questions pop up during this phase, and sometimes I need to talk with the customer or investigate the source of the problem more thoroughly. But usually, by formulating precise questions, the answers present themselves immediately.
Phase 2: Design
While understanding it, I get better at formulating the steps. These steps, pre-requisites and promises (any sum method promises to return a number which is not null, for instance), come up and begin to form a sketch of how the problem could be solved. Imagine you wonder how to cook soup. The more detailed you write down what this soup should be like, how the available ingredients should blend together, you gradually approach how you would actually do the cooking. That’s the design phase.
Phase 3: Implementation
You got your idea of how to solve the problem. Now you’re leaving behind pen and paper and start to work it into whatever programming language or development environment you are using.
I use this approach for most any problem analysis, because phase 1 and 2 don’t really care about the implementation. So whether I’m creating a novel, a handbook, a program, a business process, or soup, I use that approach to figuring out what to do (given it’s complex enough to justify this extra work).