I think, honestly, that this is a reasonably efficient workflow. Googling takes the place of 'ask a coworker' in situations where that's not possible.
Really, why spend 10 minutes noodling around trying to solve the problem via manuals/thinking, when you might get an answer in 30 seconds otherwise?
IMO, this post has a bit of "Get off my lawn" to it.
I've always encouraged the people I mentor to ask questions of people who may know before spending lots of time on a problem. You get the same level of learning, you get the same realizations, the only thing you skip is your wasted time.
To a large extent I agree with you, but there is one thing I pause about:
You get the same level of learning,
you get the same realizations, the
only thing you skip is your wasted time.
Here we diverge. As Confuciussaid:
Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
Sometimes, and for some things, that time spent working out bits of a solution - even if you fail and ultimately ask for help - is not wasted. Sometimes it's priming you to be in a better position to understand the solution you're given.
But do I really need or want to know, remember and understand the nuances of each and every of my problems?
For example, we have a lot of legacy Delphi code. Delphi 7 has a bug in which it gives incorrect compiler warnings for some of it. I don't care one bit about the history, details and nuances of the bug. The 2 hours I don't spend examining that are 2 hours I can spend learning something useful instead.
It's not yes or no. It's not everything or nothing.
* There are cases where the fastest thing to do is ask your colleagues.
* There are cases where the fastest thing to do is ask your friends (if you have any).
* There are cases where the fastest thing to do is ask Google.
* There are cases where the fastest thing to do is ask StackOverflow.
But there are times when it's best (and not necessarily fastest!) to work on it for a while to see if you can either solve it, or at least get your mind around it enough to understand the solution when it comes.
The very best programmers/engineers/employees/founders/people know when it's which case from the above.
Honestly, at this point it's about the asker's urge to learn -- if he blindly looks for an answer, then he won't take anything away from it. If he looks for reasons, then he'll get them.
This is true regardless of which method he'd use to figure out a solution.
I do agree it's not binary -- I'm learning Objective C right now, and spent two hours last night tracking down a crash that was ultimately linked to not understanding retain and release semantics. That is worthwhile, and a situation where just asking someone for a fix wouldn't work.
But I think that's a learning issue. If you already know the majority of what's going on, and the rest is just finding a key, then I think searching/asking is perfectly valid.
And really, wouldn't you argue that a programmer worth being called such would always attempt to be involved with finding the answer?
This workflow is efficient for the programmer, but not for the co-workers or the company. When you go ask a co-worker, you break their flow, which can cost them 15 minutes of productive work while they get their flow back.
If you can figure it out in under 15 minutes, you've saved time overall versus asking the co-worker.
The good news is that by merely attempting to phrase a question, people often solve their own problem. So, when a coworker bugs you, just look at them without processing anything they say. If they finish talking and don't have an have an 'aha' look about them after a few moments, only then do you actually switch mental gears, ask them to repeat the question, and go on from there.
I love being able to answer peoples' questions, and I hate asking them. I guess it comes down to I like helping, but I don't like feeling like I am being a burden. My process is like this.
1) 15 minute gamble on self solving intuition
2) Exhaust any possible solution I can think of even if I have to "be the computer".
3) Google
4) Documentation
5) Ask a co-worker
Sometimes I'll skip from step 1 to 5 if it is dealing with something that I rarely use. Typically this means I don't expect to remember the problem or solution later because of how rarely I visit this part of the application.
This is probably not the best way to do it, but I just remember things more often when I solve the problem myself. After 3-6 months with a new technology, I am frequently able to solve problems in step one.
when you _might_ get an answer in 30 seconds otherwise
Not arguing that this can't be an efficient workflow... but I think you pointed why it can fail and fail often. What if you don't find what you are looking for on Google and end up down other roads or dead ends that don't provide the real answer? In those cases 30 seconds can turn into 30 minutes pretty quick.
Really, why spend 10 minutes noodling around trying to solve the problem via manuals/thinking, when you might get an answer in 30 seconds otherwise?
IMO, this post has a bit of "Get off my lawn" to it.
I've always encouraged the people I mentor to ask questions of people who may know before spending lots of time on a problem. You get the same level of learning, you get the same realizations, the only thing you skip is your wasted time.