[karmakaze]

A lot of emphasis is put on programming "the code". What I find can simplify a lot of thought processes is to think of the overall action from the outside of the code. Often a system is transitioning from one persisted, consistent state to another persisted consistent state. Reasoning should begin from what needs to be applied to the persisted state at the lower level (e.g. SQL statements). The 'consistency' can be thought of in terms of invariants which must be upheld. Once you have those in mind, you only have to work out the 'plumbing' details of how the code is structured to get the job done.

Besides that learn the details about your infrastructure (what it can and can't do, datastores, networking) and your frameworks/libraries. Don't be afraid to go outside the frequently painted lines to do what's possible, not only what's been done before.

In terms of programming, it's good to learn other languages and formulations that let you think at a higher level. e.g. using map or reduce level processing or single assignment of variable values, immutable collections once constructed, etc simplifies code construction while avoiding common pitfalls like off-by-one errors, shared mutable references, or distributing a single piece of logic in different places. Pay a lot of attention to how to name things, lower level constructs should simply be what they do, higher level things go toward why they're being done. Separation of mechanism (lower implementation) and policy (higher level uses) fits naturally into structuring which is easy to work with and highly adaptable to new requirements.

Lastly don't refactor dogmatically. Choose what the factors are before redrawing the system/process along those seams. Deal with each factor once and avoid having to write, reason about, test factors in combination whenever possible.

I wouldn't consider any of these things as 'hard' (unless you meant technical), it only seems so because they are considered later (after being painted into a corner) rather than sooner.