> Everyone has an opinion, assholes included.

Not true in my experience; there are plenty of apathetic floaters who don't care enough to form an opinion about anything. They use what they're told to use, don't look around at anything, don't form comparative opinions, and don't care. They all produced terrible work, because they didn't care enough to form opinions, or look around for better tools and techniques, and so never learned anything

> Many of the best programmers I know contribute nothing to open source because of confidentiality agreements.

Absolutely. But again, it's a good sufficient tell, not a necessary quality.

> You mean when it's fun specing something out or at 4 in the morning when everything is down?

Yes. You want them to fundamentally enjoy what they do. Dispassionate automatons may exist who nonetheless churn out solid work, but in my experience there are far fewer passionate, horrible developers than uncaring horrible developers, so it is again a good sufficient distinguisher to help find a good developer.

> And what does it cost to maintain or fix it? There are 2 ways to find out. a. Read the source. b. Wait a year. Which would you prefer?

c. Contact previous employers/coworkers, see what their reputation for shipping (and shipping quality) is.

> Who cares? What they do on their own time is their own business. This is an indicator of nothing.

It's an indicator of intellectual curiosity. Again, intellectually incurious developers who nonetheless do solid work and stay up to date may exist out there, somewhere, but I've never met one, so it's yet another good sufficient identifier.

> This is important for all people, for all things, so it doesn't even need to be on this list.

If you really believe that, you haven't met a lot of hiring managers who completely and utterly forget about it or think it is unimportant for technical positions. There are people who absolutely need this reminder.

> b. Hire a programmer to hire a programmer.

Turtles all the way down?

That's a awfully large sense of entitlement there, one that is very, very difficult to support. I'm surprised such a comment is coming from you.

While I don't excuse idiot HR recruiters and headhunting firms on quotas, there is a level between clueless and mastery that a person can attain that allows them to make the comparative judgement required in the hiring process.

I know little about law, but enough to hire a semi competent lawyer, I know little about masonry, but have successfully hired a firm to rebuild a chimney. They are probably not the absolute best at their professions. They probably take shortcuts that purists wouldn't like. So be it. They get the job done and that's good enough for me.

There is really no reason that someone with little knowledge of programming cannot properly hire or outsource a competent developer for work that they need to get done.

To suggest otherwise is only to worry about which way the mortar is spread in between the brick, when it all boils down.

Sorry if that's how it sounded; that's not what I intended.

A little background...

I have worked for about 100 managers over the years, and with few exceptions, here's my experience:

- Those who were programmers were able to understand, examine, critique, question, and drive almost anything I worked on.

- Those who were not programmers were able to fit whatever I was doing into their project plan and evaluate it only through the eyes of other programmers (who may or may not have done a very good job of it).

I have also maintained hundreds of thousands of lines of code and I can predict with uncanny accuracy that which was written for a programmer boss and that which wasn't. There is a difference.

There are probably billions (or trillions) of lines of shit code out there that never would have made it through peer review of almost any programmer here at hn. But no one had to worry about that; they were written by programmers working for non-technical bosses.

Hope that paints a better picture of my skepticism :-)

It's not just a matter of 'getting away with something' either. A badly managed programmer won't know the larger scope of what they are doing, or even worse be doing something the wrong way because they 'have to', and the code inevitably becomes a series of hacks fixing whatever the latest requirement or problem is.

Beside, if everybody become a programmer, who will produce the pencils?