As a point of reference: A lot of people sought out -- and praised -- advice I gave in the SDK support forums. I would typically figure out what their problem was without seeing any code. Many attributed the popularity of the SDK I was supporting to the fact that I was supporting it, and as the SDK became irrelevant about 3 months after I resigned from the company, there may have been something to that.

Another thought: A lot of the teams I was supporting had multiple developers, so presumably had already shown the problems to other "fresh eyes."

I'm certainly capable of getting stuck looking at a problem wrong, and I have benefited from talking to other developers. For me the benefit is typically because I've gone down the wrong design path. It's been a LONG time since I couldn't debug my own code faster than anyone else.

When you're working on a design, sometimes being good isn't an advantage; you can see a solution to a problem, and you work to solve it that way, but it turns out there's a much simpler solution to the same problem. If I weren't as confident of a programmer I might work harder to find a simpler solution. At the same time you can spend hours of time trying to come up with the perfect design that would be better spent just coding, so it's a hard balance to always get right. And for problems that really need a complex solution, well, the average programmer may decide that they can't be solved.

I've typically (with one painful exception where the match to my skills wasn't ideal) been the developer that everyone comes to for advice everywhere I've worked. I've known a lot of excellent developers easily at my skill level or beyond, and yet MOST professional developers I know are nowhere even close, and even among those I consider competent I feel like 10x may be insufficient to describe the real difference.