Many organizations care, but frankly have little to no hope of actually differentiating good and bad programmers. I personally have seen this in both sw dev fi

Many organizations care, but frankly have little to no hope of actually differentiating good and bad programmers. I personally have seen this in both sw dev firms and other firms (financial and biotech) that have internal teams of programmers. Hiring a poor developer was somewhat in the noise in overall outcome - in other words, a slow programmer who produces some code that "kind of" works might be judged as above average based on other, non-engineering talents (personal communication skills, perception as non-trouble causing, etc) Part of the problem boils down to "it takes one to know one." Even that assumes that you've already got a good programmer and that person has hacked the hiring process enough that they can effectively filter out bad programmers. I'm thinking lately about how we (the hacker community) can help non-IT people judge programmers. Credentials don't seem to be the answer, personal networking is hard, judging code is usually a flame-war between language acolytes, and in the meantime . . . users are working too hard. Heck, your typical (non-software oriented) organization can't speak to whether or not language X or Y is the appropriate fit for solution development. An interesting angle for me would be to hear your thoughts about how to build a good programmer and how you would market that person to employers, assuming that employers don't have a super-hacker on board who can help with candidate filtering.