Never mind the language, the programmer is what matters(p.einarsen.no)
p.einarsen.no
Never mind the language, the programmer is what matters
http://p.einarsen.no/?p=151
15 comments
Not to mention the fact that really good programmers hate, hate, hate working in lousy languages.
I'd much rather have good programmers on a bad language than bad programmers on a good language.
I'd rather have good carpenters working with a few blunt tools than rubbish carpenters working with a good stock of sharp tools, but I don't think the good carpenters would stick around very long.
Then that good programmer would leave to go work on a good language.
Thankfully, we don't have to choose between good programmers and good languages. Organizations that care can have both.
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.
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.
A lot of organizations are completely hopless when it comes to identifying a "good language" (for the problem domain), too.
"Organizations that care can have both"
Exactly. Good Programmers vs Good languages is a false dichotomy.
Exactly. Good Programmers vs Good languages is a false dichotomy.
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.
Then again, using good languages tends to attract good programmers, so this mostly appears to be of academic interest.
I don't think the issue is as black-and-white as the headline. It reminds me of the bit Top Gear did where they "proved" that a BMW M3 got better mileage than a Prius. http://www.youtube.com/watch?v=dKTOyiKLARk#t=50s Their point, of course is that the diver makes a huge difference - enough to offset a huge difference in cars. But obviously the show wouldn't exist if all cars were equal!
In ALL areas of skilled performance, the performer matters more than the tools, including mental tools. Like the old adage, "There are no dangerous martial arts, only dangerous martial artists". What the individual brings to the project matters more than what tools he uses. As for "it is the culture that matters" nonsense - a culture is just support for the individuals involved; a few competent people are going to trounce incompetents no matter how they are organized. Culture is just another type of tool.
Most programs are written by teams these days... it is the culture that matters.
Culture provides support, best practice and good staff. Some good languages will never be widely used unless they have good communities/projects associated with them.
Culture provides support, best practice and good staff. Some good languages will never be widely used unless they have good communities/projects associated with them.
just the level of entangled abstraction that C++ can bring to your project is staggering.
this kind of reminds me of the quote in "balls of fury" movie "game not in paddle...game in you..."
Yes, but that doesn't mean the language doesn't matter. If programmer productivity is variable by 10x, and this study shows that the language affects their productivity by less than the difference between programmers, that's still a huge difference.
Using the wrong language can drop the performance of a rockstar programmer down a weight class.