1. The remaining problem is smaller.
2. Your subconscious mind has had longer to chew on the tough parts.
3. Your mind is cleared of the clutter of worrying about the part you have solved. It does not jitter. It can focus more on the crucial remaining part.
4. You have created tools not only to solve the problem, but to think about the problem in a clearer and more abstract way. With details already handled you can see the forest for the trees.
5. You are more familiar generally with the problem and any relevant documentation.

After you have stripped the problem bare of every conceivable fancy feature, next divorce yourself from any concern that anything could go wrong. Assume you have perfect data. Assume that when you look something up in a table it will be there. Assume your references will never be null. Assume your casts will never fail. See if you can then write the code. You can then focus 100% on the normal case.

While you are doing this, scores of what-if-x-happens? thoughts may crowd your brain making it impossible to focus on the normal case. Just create a comment section labelled worries, and jot your concerns there. Later, go back and review that list. Often your code will handle those pathological conditions in the wash. Others you will have to add code to deal with. As you cover each concern, delete it from the list. The key is not to overwhelm your brain with too much detail.

By focussing on the normal case first, your code will tend to be better structured, to emphasise the usual case rather than the pathological. Someone reading your code usually first wants to understand the most common cases. I have an idea for SCIDs to make that emphasis on the usual cases even easier.