That's true. But it (generally) doesn't let you discard your wrong ideas quickly, which is where the approach I was trying to describe gets most of its benefit. What you describe is much more akin to a waterfall model with a bunch of pseudocode and design up front but without an automated tool (the computer) actually able to run your program and tell you if it is going well.
That depends on which wrong ideas you're thinking about.
Actually writing down pseudo-code is good at flushing out hidden assumptions, points of confusion, etc. I've found that tracing through pseudo-code can help identify bottlenecks and design flaws. And it is all much cheaper than a real program. So you get to discard a lot of wrong ideas quickly.
However coding up a test program and being able to run through cases quickly on a computer catches slightly different classes of mistakes. You might not catch a logic error in your code, but you are more likely to figure out how an external API works.
I think that both skills are valuable, and both let you discard wrong ideas quickly. They just catch different kinds of wrong ideas. :-)
