Oh, no, that's not what I meant.
There are two types of programmers: Those that ask, "How do I make this go?" and those that ask, "How should this go?"
I like to call the first group High school programmers. These are the kind of people who when presented with a task take their first idea and start trying to make it work. When it doesn't, they just keep tweaking it until it does work. Then it's "done."
I call them High school programmers because this is what High school students do when presented with an error message. "Oh, that's weird. Well, I'll just change this over here and try it again. That didn't do it? Ok, what about if I do this? Still no? Well what about..." They just care that it works in the end, they don't really care how it works or why it works or why it didn't work in the first place.
The second group are the ones that not only want their code to work, but want it to work the best it can. These people are probably going to consider alternative implementation approaches, designs, and architectures. They're probably going to refactor their code to make sure it's as clean and efficient as possible. They may even go so far as trying different things before making up their mind (prototyping, if you will).
This distinction actually is important. You obviously want the How Should I's working with you and not the How Do I's. Simply because their work will be better: cleaner, more maintainable, more bug free, more extensible, and believe or not finished faster.
Its important because this is the quality you're actually looking for. I've read many blogs where people claim that you can't be a good programmer and leave work at 5pm. This is simply ridiculous. Certainly your How Should I's are likely to be more obsessive, and therefore more likely to get caught up and work longer. But there is absolutely no reason why a How Should I can't have a life outside of work, leave at 5pm, and still be a great developer.
I also think that being a How Should I is a necessary condition to qualifying as Smart and Gets Things Done.
And on top of that, being a How Should I is very likely to also make you a top 20%-er.
You can also see this quality in The Pragmatic Programmer's definition of a Pragmatic Programmer,
Tip 1: Care About Your Craft
Tip 2: Think! About Your Work
So if you're interviewing, or reviewing other people's work, or simply working with other developers, this is a quality you should look for and appreciate.