I couldn't disagree more with the central point of the article: that newbies should only ask for help from expert programmers as a last resort.
An expert may be able to solve an issue in seconds that a might stump a newbie for weeks. Moreover, a newbie will learn much quicker if given guidance from an expert than if left to their own devices.
I have been in both situations, learning from experts and sharing my expertise with newbies. I have always been happy to help out others and have certainly been shown the same helpfulness by people more expert than me.
I absolutely agree with the article on this matter.
While what you're saying is 100% correct, I'm now seeing first-hand (we're dealing with a bunch of new hires at our company, and I'm the most senior developer on the floor) the reasons behind this.
The biggest reason is this: 9 out of 10 hires haven't yet cultivated the art of researching for themselves (we're speaking entry level programming jobs). If you give them an easy way out, yes, they do benefit more in the programming aspect in that they now have an answer and have gained a jewel of information; but they're missing out on researching for themselves. The art of looking for an answer. Cultivation of the persistence that is required of good programmers, both in searching for and implementing any given solution.
These talents are worth more than the coding knowledge itself. The coding is propositional knowledge, but getting the solutions and doing it right is propositional knowledge and worth the wasted weeks.
Research of the sort we are talking here is easy, in that it isn't mentally challenging. Doing a google search and then sifting through all the articles does not require any skills other than patience, just as searching through a 1,000 page book to find the page you want doesn't require anything more than patience.
You don't learn anything by these actions. You learn by understanding the solution, and the sooner you can find an explanation for the solution the better, and in my opinion there is no quicker way of getting to the solution than by asking an expert.
Although to a large extent I agree with you when you say "[Resaerching] talents are worth more than the coding knowledge itself.", I'm not sure you're accurately representing the author's position.
Particularly his last acceptable answer is "If you have a friend who is knowledgeable on the subject... I don't care if you bother someone outside the organization with endless questions."
What the author is interested in is not having new employees disturb old employees with questions, although having new employees understand researching is a solution, it isn't his goal.
I believe it depends on the situation. Most cases, a little bit of research beforehand almost always helps.
When you go to the expert, you can talk about what you've found so far and how you think you should proceed. This tells the expert that he is not spoon feeding you.
It also makes the discussion more interesting since you are coming to the table with your ideas and trying to refine them using the expert's knowledge, which, I have found, is the best way of learning: finding out what an expert would do if he were in your shoes.
I agree with alexkearns. Having been in both positions I would have to say that you are going to build a better team by letting them communicate with each other. IM, IRC and email are excellent tools for this, allowing you to easily decide when to answer their questions.
How is the new programmer supposed to integrate with the rest of the team if they don't ask questions? As well as the fact that Google generally sucks for programming questions these days. Your project will progress much more quickly if the newbie spends 5 minutes with a senior developer learning than 3 hours with Google sifting through answers they don't have the experience to analyze.
I only ever do ask one question in an inverview. I decsribe a simple application and then ask the candidate to design the database schema and business objects to support it. That usually takes up the time I'm given with the candidate, and tells me a ton about what techniques and technologies they've been exposed to and their maturity level working with same. I also watch for how willing they are to involve me in the process. The best team candidates have me working along side them (but then I get to toss in a few curve balls)
I would ask "What are we looking for?"
A correct answer requires great insight and pretty much compels the candidate to continue and explain how they fit the description.
An expert may be able to solve an issue in seconds that a might stump a newbie for weeks. Moreover, a newbie will learn much quicker if given guidance from an expert than if left to their own devices.
I have been in both situations, learning from experts and sharing my expertise with newbies. I have always been happy to help out others and have certainly been shown the same helpfulness by people more expert than me.