3 ms·

Thankfully, we don't have to choose between good programmers and good languages. Organizations that care can have both.

by al3x 17y ago

plinkplonk 17y ago
"Organizations that care can have both" Exactly. Good Programmers vs Good languages is a false dichotomy.
- apotheon 17y ago
  I don't think that changes the fact that good programmers can make a bigger difference than good languages, assuming you can effectively sort for them separately like that in the real world. Then again, using good languages tends to attract good programmers, so this mostly appears to be of academic interest.
tom_b 17y ago
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.
- apotheon 17y ago
  A lot of organizations are completely hopless when it comes to identifying a "good language" (for the problem domain), too.

Thankfully, we don't have to choose between good programmers and good languages. Organizations that care can have both.

by al3x 17y ago

Thankfully, we don't have to choose between good programmers and good languages. Organizations that care can have both.

plinkplonk 17y ago

"Organizations that care can have both" Exactly. Good Programmers vs Good languages is a false dichotomy.

apotheon 17y ago
I don't think that changes the fact that good programmers can make a bigger difference than good languages, assuming you can effectively sort for them separately like that in the real world. Then again, using good languages tends to attract good programmers, so this mostly appears to be of academic interest.

tom_b 17y ago

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.

apotheon 17y ago
A lot of organizations are completely hopless when it comes to identifying a "good language" (for the problem domain), too.