As Lord Bryon said "Knowing the right question to ask is half the answer."

And someone (probably an inscruitable japanese gentleman) said: "Each journey begins with the first step". (Or maybe it was an American and "Each journey begins when you step on the gas":).

And one of my old bylines which might have been original, but maybe not, went: "The hardest thing is not knowing what it is that you don't know".

The upshot is, simply recognising that you need to gain more knowledge is the start. From there you have several alternative routes. Sticking to coding so as to keep this vaguely on topic.

Traditionally, the route was 'plan, design, specify - then code'. This has some advantages, but I've seen several, large, highly specified and well designed projects fall behind schedule, go way over budget and ultimately flounder because seemingly insignificant details in the original specifications were based upon assumptons. mistakes or simply overlooked. Later, these proved to be so intractable or required so much reworking of the layers above to correct, that it was economically infeasible. (Anyone heard of or remember Nimrod?).

Thats why I personally prefer the RAD approach to development. Get as much as you can going as quick as you can, skipping the nice-to-haves and foregoing some "best practices" if need be, at the same time as the specification is being drawn up. The idea is not to produce great code or a complete product, but to simply prove the concept will (or can) work from top to bottom. Often, this can result in simplification, where certain "obviously desirable" features prove to be unneeded or unworkable. To me, the value of such a first-cut piece of throw-away code is often way undervalued.

Relating this all back to the asking of questions. Recognising that you are almost certainly not the first person to try and do what you are doing, means that if you can get the willing ears of a sufficiently large group of your peers (coders in similar fields), then asking "the question" can often save you a large amount of effort pursuing (whether through books, reading code or prototyping) the wrong direction. Sometimes just asking the most basic question of such a peer group can get you pointed in the right direction.

Hence the true value of the interactive nature of PM:)

Of course, there will always be those who won't hear or will simply ignore the answers, but noone should be afraid to ask their question -- at least once.