This entry was posted on Thursday, August 9th, 2007 at 4:54 pm and is filed under Life and Career. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
It is not my own writing, but find it very interesting and want as many people to read as possible, especially those with high demand of IT in their organization. It answers a lot of question, definitely. It obviously leaves or even create new open questions. Whilst it talks specifically to Perl programmers, I believe it commonly applies to other languages as well. Anyway, enjoy !!
I was invited to a wonderful dinner party (I swear it wasn’t too spicy Sarah!) with some St. Louis Perl peoples this week while I’m here on business. At one point we were talking about hiring programmers, specifically Perl programmers.
We agreed on the following:
(1) Finding good programmers is hard in any language. And that a good programmer can be as effective as 5-10 average programmers.
(2) Average pay rates between equivalent programmers are out of sync and are based more on the language used than the skill of the programmer.
(3) You don’t need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.
(4) You should seriously consider allowing your expert developers to telecommute full-time. Restricting your search to programmers who live in your area or are willing to move limits the talent you can acquire. Arguments regarding “face time”, productivity, etc. can easily be nullified when you look at how some of the largest and most successful Open Source projects such as Linux, Apache, and Firefox are developed by individuals rarely living in the same time zone or even country.
(5) We love Perl and think it’s a great language that you graduate to after you have been forced to use less agile languages such as Java, C/C++/C#, etc. Not necessarily a first language you get your feet wet with and then move onto a *cough* “real” language.
Many people in the Perl community have been writing on this topic lately and wanted to share my opinions on the subject, as it is one I have put many hours of thought into. Doing my best to keep this language agnostic as I believe these tips can be applied to any programming language. I will however, use Perl in some examples as it is my preferred language.
What is an expert programmer?
Experience is key, but not necessarily in ways you might imagine. Time in the saddle, with a particular language is not as important as diversity of experience. Someone who has worked in several disparate industries, a generalist, is often a much better developer than one who has spent years in the same industry. There are exceptions to this, but in general I have found this to be the case. Bonus points if your developer was a systems administrator in a former life.
Some of the best developers I know were originally trained as journalists, mathmaticians, linguists, and other professions not normally associated with software development.
Experts use better tools and care deeply about their craft. They aren’t assembling bits on an assembly line, they are crafting a unique product to solve a unique problem. Experts are lazy, they work smarter rather than harder. Experts prefer the easiest solution that gets the job done. Experts aren’t interested in creating complex solutions simply to have the complexity, that misguided egoism is the territory of more junior developers. They often get it right the first try and almost always on the second one.
Simply put, experts write readable code. They comment and document it appropriately based on the complexity and criticality of that particular piece of code.
All of this pays huge dividends when the next developer has to pick up where they left off. Especially if the next person isn’t an expert.
More reasons you want an expert programmer
Is your business technology oriented? Perhaps the software you create is even your main product. If nothing else I’m sure we can agree that if the software your developers create is to some degree critical to your business.
I’ve worked in many different environments, with people of every skill level, and it’s very easy to tell whether or not a company has expert developers. Do you often find that the software is down? That it has as many bugs or even just idiosyncrasies that make no sense to the user as it does features? Do the users find it difficult to use? Is the problem at hand relatively simple compared to the training or documentation necessary to begin using the software?
If you answered yes to any of those questions you more than likely have average or below average developers.
When you work in an environment with experts things simply work. They are easier to use and require less initial training. The software is easier to modify. Requested changes happen more frequently and easily. Things just flow. It is the difference between Apple and Microsoft. It’s the difference between the iPod
As with many things in life, sometimes you get what you pay for.
Freely taken from: http://blog.revsys.com
Bookmark to:
