I know that when I talk to people about considering developing Drupal sites, I tell them that there is a bunch of time that you need to spend researching the best way to get something done. For some programmers "research" means going to an online reference with lists of function syntax. But with Drupal you have to add to that: reading issue queues, support requests, forum posts etc. (and writing to all those as well) to evaluate what the best direction is for a particular solution.

The benefits of this process are great. You end up meeting great people and leveraging a huge amount of work created by others. But it does take an investment of time.

As many have noted, d.o. can add all kinds of tools (the newly launched "recommended version" feature being just one -- go Derek!!!) to make this process easier and faster. And that will happen. I particularly like Florian's suggestion about free-tagging on the module pages.

But being a good Drupal developer requires evaluation and analysis of a lot of moving parts:

These are the "moving parts." As daunting as it might seem to engage in such research, it does get easier, even as the number of modules grows. One begins to "know" modules and families of modules like you know friends (who is engaged to whom etc. :) 

I think part of the "problem" might be folks' expectation that things "should" be easier. I'm certainly for making things easier, but not at the expense of making the barrier to entry for module developers higher. I think it is a low barrier to entry that has contributed to harnessing a huge amount of energy.  Overall, the quality and quantity of contributed code to Drupal is impressive.

Shai
content2zero