This is actually good, its how I do it, and I have success. You see programming as an abstract mechanical thing rather than abstract descriptive thing.

Take a look at http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm and get the gist of the symbols, then chart out things like if, if/than, while, for, etc. Don't forget do/while, since this is also a fundamental, but its not always represented in your language of choice, and is sometimes simulated with things like an infinite loop with a break.

Move up to some simple programs. These symbols don't represent data structures (arrays, objects) so you can fudge that part.

When it clicks then stop using it. But keep in mind, when you run across something where the logic is confusing, or especially if you can't figure out a clean way to represent the flow, come back to your old friends, and you'll be amazed at how they will guide you. I still fall back on flow charts, they aren't a crutch, they are a tool.

I was amazed when I saw some of the smartest programmers I know drawing pictures of their problems. I always thought that you had to do everything in your head, but that's definitely not the case. So draw pictures, figure out how they translate to code.

If you are a visual learner, you should make sure you can draw statecharts (not decision/flow-charts), process diagrams, UML-style diagrams by hand. Learn the conventions. Then learn the design-patterns in the gof book and make sure you can draw a singleton, delegate, etc... Next bust out a notebook and start trying to draw your solution (by hand) before you sit at a keyboard.

IMHO all of the UML diagramming software are a bunch of crap but being able to understand a bunch of code as a picture should help allow your brain to see the forest for the trees.

That's interesting, and actually quite encouraging: it suggests that you do think in terms of abstractions of the problem you're trying to solve, which is arguably the most fundamental skill in programming. If your difficulty is that you haven't got the mechanical process of turning your thoughts into code down yet, that's a much easier thing to overcome.

Could you share with us what books and programming languages/tools you've been using? While there are certainly common ideas, different types of language take a different approaches to describing a program. Maybe whatever you've chosen doesn't suit your way of thinking particularly well, and you would find another tool more intuitive at this stage.

I can see how that mismatch would feel frustrating - more so than if you couldn't see the solution and had to muddle about in exploratory code to discover it.

re "practice framing": I find that asking the question is very helpful for clarity - and then defining the key nouns in it.

I dont ever see words. Sounds like you might need practice figuring out how your pictures relate to code.