Why Rockstar Developers Don't Ask for Help

I second this.

When you frame the question to ask so someone for help sometimes you tend to get the answer yourself. I've been practicing rubber duck debugging for a while and it has proved quite successful.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

You are correct, and this is a pervasive problem. When I was a tutor, I learned to answer their questions not directly, but showing them how the material they already have can supply it. "Well, let's start with the index, , ok, let's read chapter four from the top, together ..."

So the same thing could be applied, "Lets go to your desk, let's look at the manual together, why don't we google together" etc.

The lesson to the student is, "I could do this faster myself", and they'll stop asking you unless they really need it.

I think there's a lesson here, but it's not "Don't ask for help, even all the time."

To the contrary, I'd say something like: Ask yourself for help, first. If that didn't work, you might have a worthwhile question. This also requires you to be open to other people asking for help, and my greatest worry about this rule of thumb is that it makes people disinclined to help _each_ _other_. We're not cogs, human teams have value for good reason, and it's not just design or architecture decisions.

Sometimes we need to be "sounding boards" for each other.

Years ago, I'd get pulled into ridiculous flamewars on open-source mailing lists when I had run into a relatively simple issue. I was annoyed that each time I asked for help - the type of help I often provided myself - that inevitably whomever was paying attention to the list at that time of day would jump all over me and treat me like a n00b. I didn't want to come out restating my entire experience with a project before answering a question, but these flamewars aside, I found that often people would help anyway, but that sometimes the answers made me feel dumb.

This came down to asking well-informed questions. I would try to predict the clarifying questions that I would have, esp at my most cynical or annoyed time of the day, for someone else. I would end up with a page and a half describing my question, something some people might TL;DR, but probably wouldn't solicit a bunch of one-liner insults.

Ninety percent of the time, in composing such a message, I was able to answer my own questions. Unfortunately, that means that my presence in mailing list archives has my worst work, and that much of these messages never saw the light of day. I would just have an "ah-HA!" moment, along the lines of:

-- "And then even though I already tuned the kernel settings as recommended in [2], and installed the proper dependencies from the PP --- OH SHIT! I'm using the default packages and not the ones from the PPA."

Discard Draft Problem solved. ;) --

In these situations, I actually avoided asking other people for help by asking myself a question, but if I had been able to complete explaining my problem and my confusion to my satisfaction, I'd simply hit 'send'.

Dealing with people in-person is a little different, that's where the 'sounding board' comes in. If you respect your teammates, you can just kind of spitball a little about, "Hum this is really frustrating, are you kidding, Feature X in Package Y is implemented with a Dorner-Lannister sort? The Fuck? How stupid is.." And an intrepid teammate may say something like:

-- "Yeah. I mean. I'm not sure that's the decision I would have made, but I spent a good two days fighting with this exact problem a couple of months back, let me find you a mailing list thread. It will make you furious, then you can go outside and have a walk. Then come back inside and do it that way, so that you can get on with life." --

Or such conversations may be less existential:

-- SMASH SMASH SMASH keyboard "What in the actual fuck?! I can't stand cut! How has civilization progressed so far without a better way to grab output separated by variable lengths of spaces?"

"Bro, do you /even/ awk?" --

:-P

I consider that to be asking for feedback, not help.

This can be overdone too. It depends on whether the junior developer has even tried or thought about it before asking for help. If the rule is to ask first and always, the junior developer might as well not be there because the senior developer is doing all the work awkwardly via the junior developer, and the junior developer is not learning how to do anything except say "what now" to the senior developer all day.