A Guide to Hiring Programmers: The High Cost of Low Quality

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:

• Finding good programmers is hard in any language.  And that a good programmer can be as effective as 5-10 average programmers.
• Average pay rates between equivalent programmers are out of sync and are based more on the language used than the skill of the programmer.
• 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.
• 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.
• 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.

Why is it so hard to find good programmers?

The simplest reason is when a company finds a good developer they do more to make sure that person is happy which leads to longer tenures. Better salary, more flexible working conditions, good tools, interesting projects, and better perks can often keep a programmer working for you longer.

Another obvious reason is that experts in any field are small in number, so your possible talent pool is limited. This leads managers and HR departments to settle for average or even below average developers.  I believe this is the single biggest mistake a technology oriented company can make, regarding developers, just short of not using a good version control system.

We're not talking about customer service representatives or sales people here. Just having a body to fill the seat is not, I repeat not, always a win for the company. Sub-standard programmers drag down the efficiency of your other developers with beginner questions, poor comments/documentation, and bad code that someone else will later be forced to spend time fixing.

Companies need to stop thinking about their developers as cogs in the machine. They are more akin to artists, authors, designers, architects, scientists, or CEOs.  Would your HR department rush to find the first person who would be willing to take on the role of Chief Scientist, Art Director, or CEO in your company? Of course not, they would spend the time to do a thorough talent search for just the right candidate, court them, and then compensate them appropriately. They realize that having the wrong person in that seat is much worse than having the seat empty. It is absolutely the same with programming.

Anyone who has been a developer or managed developers can tell you that an expert can accomplish as much as 10 average developers.  However, companies typically pay only a 10-20% premium for an expert over the average programmer. Whether or not their title is Lead, Architect, Development Manager, Guru or whatever nomenclature the company uses. I am not saying that if your average developer is paid $50k/year that you should pony up $500k/year for an expert. The employer/employee relationship never works like that, but what employers don't seem to realize is that in the end paying more saves them more.

Let's look at an example.  One common argument from HR departments is that they "can't find any Perl programmers, but they can't swing a cat without hitting a Java developer".  While this is fairly accurate, they are approaching the problem from the wrong direction.  If you fill your shop with 15 average Java developers, paying an average of $60k per developer you have an approximate labor cost of $900k/year for your development staff.  Not considering any non-salary benefits.

Suppose you instead took the time to find 5 experts, or at least above average, Perl developers at $120k each per year. Here is a partial list of the pros and cons of such a scenario:

Cons:

• You must spend extra time finding, evaluating, and courting these more sought after developers.
• Your company and what the developer may be asked to build may simply not be attractive to this class of developer.  Very few people want to work for a spammer or a small web design firm that caters solely to freelance accountants for example. Smart people find boring things even more boring than the masses.
• When one of them leaves the company, there is the feeling that your company's business objectives are more at risk due to having only 4/5ths of your normal resources. Or that a larger chunk of your corporate knowledge just walked out the door. This is more of a perceived problem than an actual one as good developers are better at writing readable/maintainable code, commenting their work, and writing effective documentation.

Pros:

• Each developer will be more content with their job, due in part to the higher than average salary, but also because his or her co-workers are of a much higher quality which improves anyone's job satisfaction.
• Development would require less overall communication as there are less people to communicate with.  This obviously improves efficiency as anyone who has been on a 20+ person conference call can attest to. Or read the Mythical Man Month if you want a more in-depth analysis of this phenomenon.
• Experts travel in the same social circles.  Having one expert on staff makes it much easier to find other experts in the same field, no matter what field that may be.
• You would save 2/3rds on infrastructure costs.  Things like cubicles, computers, cell phones, free lunches, training costs, travel, office space, air conditioning, electricity, etc, etc. The list is essentially endless.
• Your HR department would have 1/3rd the number of developers that it would need to take care of. Less paper work, less questions, less everything, and less turn over because of the lower number of employees.
• Oh and you'd save $300k/year on your labor costs.  Not to mention non-salary benefits such as stock options, retirement matches, health insurance premiums, perks, etc. You could spend as much as $100k/year on your talent searches and still be $200k/year ahead.  Hell, you could dedicate an entire HR person just to this task.

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 and a 400 disc CD changer with 50+ buttons.

As with many things in life, sometimes you get what you pay for. I'd love to hear your comments and opinions on the subject.

UPDATE: I've written a response to some of the questions and comments I've received on this article in a follow up post A follow up to "A Guide for Hiring Programmers"

Comments

[sales guy]

just putting a sales guy in a seat is not a win for the company either. who do you think generates the revenue to allow the company enough funds to hire an 'expert' developer? this was a good write-up, but don't invalidate the effort of the sales team; we make sure the bills get paid.

but we can all hate on hr :-)

[Steve]

Your points are valid, but sometimes money isn't enough to keep good people. I've worked at places where either the work or the corporate culture has been so poor that holding onto good people was incredibly difficult. I've also seen great places to work go sour due to a few poor recruitment choices.

I guess my point is that you can have good people, but that's only part of it. Just like with hiring exports, it helps to take a holistic view to the workplace.

Which, unfortunately, is beyond the power of many .

[lofi]

apart from being grotesquely wrong about Perl being an adequate language, this article is on the right track ;)

[Jimbo]

The problem gets worse as you move up. $120-$200k is the upper cap on engineers at any company (not just software). If you do 10x better work, you get 10% better pay. If you're a hotshot, it is simply not economical to go into industry. You do a startup, contract work, or switch fields (entrepreneurship, i-banking, etc.).

[Frank Wiles]

I agree with all of these comments, except for the Perl one ( that could be a whole article unto itself ). Sorry I singled out sales people, I do realize there are amazing expert sales people out there, it is just in my experience most of them seem to be easily interchangable! :)

[Paul Evans]

"It is the difference between Apple and Microsoft."

Interesting statement.

[Matt C]

Let's say you're right about the cost effectiveness of hiring better programmers.

How is an ordinary company to know the difference between a good and a bad programmer? An HR type who offers 2x pay for 5x the effectiveness is not likely to actually get the 5x. There are plenty of programmers (or "programmers") out there who talk a good interview without delivering much. Being able to tell a genuinely exceptional programmer is a skill in itself, and not a common one.

Also, you are assuming the hiring person is motivated to maximize cost effectiveness, rather than, say, having a large number of people reporting to him so he looks more important. In my experience cost effectiveness is not central to the thinking of manager types.

[Nick Quaranto]

All I see here is more people like me who are new to this industry and who are coming out of college soon being screwed out of good paying jobs. Without 5+ years of experience it seems like I'll be on code monkey status out of college.

[Jarvis]

I found this informative and potentially useful until I read your childish comparison of Apple to Microsoft.
Congratulations on discrediting yourself.

[Dr. Alabaster]

I've walked into a number of failing projects that were started in the latest fad language and witnessed the use of PERL save everyones hides. There aren't many other languages that have the resources of CPAN modules where much of the time, someone's already done the heavy-lifting for you.

PERL/CPAN is a great example of a community sharing their work so other members can turn around and leverage that work in their code. PERL may be "inferior" in a number of ways but at the end of the day, the stuff works, which, I'm finding, bosses seem to like.

[Gunther Hust]

I agree with most of what you have said here, but the main counter issue in my experience is that the people making the decisions can't tell average programmers from expert programmers (or average sales guys from expert sales guys, for that matter). Nor do they care to put the effort into being able to do so - after all it doesn't benefit them.

In a lot of cases, managers do _not_ want great programmers on their team, they are seen as prima donnas, and their technical leadership can encroach upon the authority of the team manager. Great engineers care most about making great products - managers care most about promotions.

The decision makers make decisions mainly based on who they know, not what they know. Getting a team of 5 or 10 average programmers together and delivering something successfully is good for the manager, even though it is not necessarily good for the company. Just like getting a team of 5 to 10 average sales guys together and making 1M in sales is good for the sales manager (whereas maybe the expert sales guy can pull in 5M in one deal).

[kalpesh]

Money alone cannot be motivating factor when it comes to retaining the best talents. Software industry has been plagued by high attrition rates. No company can win the business game with one department even if it means that department is most productive.

[Maxdogg]

"The High Cost of Low Quality" really applies to ALL fields. However high quality does demand a higher cost, just not as high as low quality and most companies are reluctant to spend more than the least possible.
As a chemist I would catch mistakes that my peers were routinely making and cause problem because of "backtracking" to fix the problems.

[rem]

Good Post. The point for job seekers is look for a Company not a Job.

http://jobhacks.wordpress.com/2007/08/01/dont-look-for-a-job-look-for-a-company/

[Peet]

Good points - except that Perl is passable only for the most *cough* simple of applications. For scale, managing complexity, readability, nothing beats Java.

[OneYearGoal.com - $100,000 in one year]

You couldn't be more right. A bad programmer is almost worse than no programmer.

[Andrew Gamache]

I need 10 Outstanding Perl Developers to work for an investment Bank in NYC. We're probably looking at 100K ++. Hopefully some Experience in the Mortgage Business (Application Development for Mortgage Backed Securities- Analytics and High-Speed Trading Systems)

This is going to be the opportuinity of a lifetime for someone.. (It'll certainly make your career) Exected Comp over the Next 5 Years is 1 Million+. No Joke. If you rock at PERL, and have Financial Industry KNowledge/Experience (Or just know alot about Mortgages) email me: agamache@optionsgroup.com
{
Compile your future.
AG
}

[lol @ perl]

We had a perl "programmer", he was very fond of the game perl "golf" and tried to play it with our valuable assignments. We got rid of his stupid ass before he had much chance to cause trouble, and from now on we only hire programmers skilled in the dot net toolset, and its served us very well.

[David F. Skoll]

So, how do you find expert Perl programmers?? We're always looking!

[JB]

Thank you for this post.

I was brought on my current project (non-Perl) when it was six months overdue. The former programmers were novices at best (more likely incompetent), which meant my job entailed progressive rewrites of their code. And, no, I wasn't being snotty about the code. They had used two (sometimes more) functions instead of arguments. BTW, one of those developers gave his notice as soon as I asked for his source code.

The VP didn't want to move me to the project because I was, "too expensive."

In two years, these guys had produced 400 "units" (purposefully vague) for delivery, or 16/month. In less than two months following the restructuring, I and a budding-expert developer produced more than 100, or 50/month. That's better than 3x previous production.

Yet, somehow, I doubt those other guys cost 32% what I did.

[Note: I wouldn't consider myself "expert," but I have a lot of experience working for a variety of clients, and I do try to do things right the first time.]

[Dave Palmer]

>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.

A common notion, but wrong.

Sure, any competent programmer can learn the syntax of a new language in short order, and most of the uber-concepts of programming do not change from language to language. But the *details* of the language take time to learn, and a program is made of details. How do I implement a menu control? How do I listen for mouse events? Is there a maximum string size? Are chars signed by default? Many of these details might be tiny and easily-learned, but there are a LOT of them, and a person who is just learning a new language has to look up most of them. That takes time (and BTW, if you're just learning a language, how do you know whether that example you looked up is well-written or not?). Further, some concepts and details just don't translate into a different language.

Really, the proper learning time to consider is not how long it takes to learn the syntax, but how long it takes to learn a useful subset of whatever standard library the language uses to perform useful tasks. I spent years getting familiar with all the details and gotchas of MFC before I felt confident calling myself an expert. Now, I've been dumped into the Java world, and suddenly, there's an entirely different big, bloated, buggy standard library to learn. AND the new concept of cross-platform issues to deal with.

In MFC, I know how to do lots of useful stuff just off the top of my head. Further, I know where many of the gotchas and pitfalls are, and how to avoid them. I know how to work the IDE. I know none of that for Java, and it will take more than a couple weeks to pick it up, no matter how diligent I am.

It is my considered opinion that no small, agile company on a tight schedule should attempt to write code in any language unless they have at least one bona fide expert in that language on staff, somebody who has spent at a minimum 6-12 months writing almost exclusively in that language (of course, I mean *in addition to* having several years of solid general programming experience).

Anybody who tells you they can learn a new (full-featured) language in a few weeks is either lying, deluded, or unclear on the concept of "learn."

[Ethan]

You have convinced me about the need to hire experts but how do I figure out if someone is an expert or not?

I am going to be hiring a few programmers in the near future but am not a professional programmer myself. I have some knowledge in sys admin and web development but know little to nothing about more complex languages like C, C#, C++, Java, etc.

How should I go about determining if someone is an expert. What kinds of questions should I ask and what kind of responses do I want.

Thanks for your post!

[Mikey]

Hmm, I see a void forming...

How do we get expert developers? It seems to me that all expert developers were once average developers. If not all, then I would say most. I'll admit that there are exceptions, geniuses. There are also those who got to be experts by working hard as average developers to improve their skills. This is where I see a void forming in your article.

I agree that an expert work force is ideal. I am saying that that ideal isn't really feasible, because it leads to elite-ism. I would say that the ideal is to have a few experts and several very eager average developers. People who will willingly submit to constructive criticism and learn to better discipline themselves, so that they can become expert developers. That road is messier, but it also leads to more expert developers.

If we are to ever meet your ideal of an expert workforce I think it must be by following this road. I say this because I know that there is only so much time that a person will devote to full time education before seeking real world experience. I think we are lucky to have a few CS Masters graduates that are expert developers.

Perhaps I am a little bias on this last point. I am a Systems Administration Bachelor graduate myself, who has been tasked with a few programming projects. I consider myself a fairly eager amateur, and had I tuned by education to software engineering I might go as far as to call myself average. If I am now an average developer it is only because I am so eager, and have been trying to teach myself the software engineering skills that you have in part described in this article.

To summarize, I think that society can only effectively handle putting people in to so much full time education. There has to be a point where real world experience becomes that teacher, along with the tutelage of the experts. However, this sort of path of advancement is circumvented by what I see as an elitist mentality of only hiring the experts.

[Міша]

I think, this applies just the same to many other professions. Sysadmins for sure. Probably -- other engineers too...

[Susan M]

AMEN - I quit progamming after 20 years not because my skills went stale but because my experience and expertise were not being valued. It seemed that additional experience was not rewarded. Companies would hire 5 junior programmers instead of 2 senior programmers. I predicted that this would come to a crisis in code someday. This article tells me that it is about to.

[OJ]

This is a great post. Thanks for putting my thoughts down on paper :)

[David G. Miller]

As the size of the project grows, the less likely it is that the tradeoff of a few highly skilled people vs. many lesser skilled people holds. If for no other reason than larger projects have a lot of uninteresting code (e.g., a lot of the UI) that isn't amenable to an expert finding an easy, compact, elegant solution. This is one of the factors that makes estimating software projects so tricky. On the plus side, hiring a few highly skilled programmers for a project that eventually requires a lot of uninteresting code is a correctable mistake. The experts come up with an elegant solution and it's possible to bring some additional people on to flesh out the rest of the program. Hiring a bunch of mediocre programmers for a project that needs a few experts usually results in a need for more people and a longer schedule with the resulting project being a bug infested piece of unmaintainable bloatware (think Microsoft products).

Cheers,
Dave

[Bad data]

"Anyone who has been a developer or managed developers can tell you that an expert can accomplish as much as 10 average developers."

One of the least fact based generalizations I have ever read. I believe an "expert" writer could have gotten your point across with 10 times less verbiage than you.

[Robert]

Thanks for spelling out a lot of what I have intuited but not formalized in a decade of working with and managing programmers.

[Alex]

Part of me thinks this article is more sour grapes about low perl developer salaries vs. java developer salaries, otherwise why mention java vs. perl at all and instead, say, "average x programmer vs. expert x programmer" .. then I think your point would be more clearly heard. The problem we have in the java world is overpaid average programmers.

Honestly, salary is more about demand, and less about skill. Technical merits of either language aside, Java is a high demand language with a vast array of available cool projects. Perl not so much. Most perl jobs I've come across have been maintaining someone's glue code. I only know one Perl programmer with a 6 figure income, and his project is being converted to java. I know several Java developers with 6 figure incomes.

But here's another thing, I'll take 4 good programmers who can work well together, vs. the 1 hotshot, because the hotshot is the one that's going to have a huge ego, be a pain in the ass to work with, and end up hurting the company more than he helps. Ideally, I want an expert who can work well with people, and raise the skill level of his team members.

[Foo, the Cal Poly Computer Engineering grad]

I agree with most of the article. Unfortunately, most of the people doing the hiring don't get it. It is difficult being an expert in a company when there are no others, even worse if your superiors don't recognize the expert. I love the bit about experts being lazy. I tell my boss that all the time, when it comes to my design decisions and implementations...I don't want to revisit the code, and if I do, it is well documented, flexible and extensible. To the expert, it's just a language, architecture, operating system, etc. The expert has full understanding of languages, architectures, operating systems, programming, etc.

I have to totally agree with the simplicity. Much too often I see "engineers" trying to reinvent the wheel. Many times, what you are trying to do, someone else has had to deal with too and the solution is out there (many times it has many hours of use, debugging, etc behind it). Simple is always better. If I want to have fun with the egoist guys, I show my full understanding of the grammar of the language and write totally obfuscated code that is both syntactically correct and grammatically correct.

I know this article was about hiring, but you have hit a sore nerve with me about the state of software development, how it is handled and how it is approached by companies.

I'll stop rambling now.

[Mycroft]

"Some of the best developers I know were originally trained as journalists, mathmaticians, linguists, and other professions not normally associated with software development."

Sorry, don't agree with this statement, nor the one about Perl being some great language. Every language has it's place, and you need to use the right one for the job, which a whole course was dedicated to in my BSCS.

One way to identify these develpers is to ask them what tools THEY have created to save time and effort.

[Jesika]

"They are more akin to artists, authors, designers, architects, scientists, or CEOs."

I appreciated this line. Poor draftmanship of architecture drawings causes a lot of grief and time spent chasing the error in all it instances. What's worse is if the error isn't caught and affects construction. It can result in possible failures and lawsuits.

In regards to programming, we had one individual modify AutoCad in significant ways with no documentation. Suddenly he is no longer with the company, and there is no one that knows what he did. Those of us in the company who use AutoCad are now struggling to change things to suit our needs, but none of us are programmers by trade. We do our best and have found some loopholes that we can use to bypass his modifications.

Documentation is very important! Not all of us have time on our hands to decipher what happened.

[Pete Kruckenberg]

The place I started at a year ago (OpenAir) is a text-book implementation of points made in this essay. Best job I've ever had, for all the reasons mentioned here.

And we're hiring. http://jobs.perl.org/job/5848 or click the link below.

[Jason]

Great points on the business efficiency of an "expert" versus the "average" (debugged features / dollar / hour), I totally agree. However, I bet either your Perl friends are just average Java developers, or you have too many cats. The same "our product is superior" attitude seems prevalent in many expert groups. That misguided egoism is the territory of more expert developers. I know a lot of crappy Perl guys and if they just used Java the whole world would be happy. ;)

[Mike]

You stated "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. "

From my point of view as a Perl programmer, these sound like management flaws...not programmer flaws.

[Steve Fink]

I often hear about these enormous factors of efficiency differences between average and expert programmers, and to some extent I believe them and have witnessed them personally. But at the same time, it always reminds me of Amdahl's Law. I can easily believe that programmer A is a full order of magnitude more effective than programmer B, but *only while working at full speed*. And there are a lot of things that a programmer must do besides working, and many more that a programmer might do: meetings, scheduling, bug triage, slashdot, lwn and other technical sites, day care disasters, etc.

I'm not even saying that all of those things are a waste of time -- I doubt someone can become an expert programmer without spending some amount of time keeping up with the state of the art on various web sites. But the fact remains that a superstar programmer reading slashdot is getting no more accomplished than a halfwit programmer reading slashdot. And I'm willing to bet that non-programming tasks are well above 30% of any programmer's actual work hours. Sure, for a week or sometimes even a month that might be the case, but not over the course of a year. And... let's see... at 30% time, that 10x boost is now down to a 2.7x boost.

You have to consider what percentage of the overall job of a programmer is actually subject to the 10x (or whatever) speed difference.

That said, I fully agree with your basic premise. :-) I suspect that if orders of magnitude really *were* possible, then this wouldn't even be a debatable point. But the real-life differences in performance are still easily large enough that a 100% salary premium should be considered a cheap way to boost productivity.

[James]

Every wants to hire an expert, but no one wants to let more junior people get the experience that allows them to become experts. I have seen this for over 5 years now, so when I hear people complaining about the lack of talented coders, I feel no pity for them.

[Nathan Myers]

Five to ten times? You must be joking. I know someone who worked on a project (a joint effort between Ericsson and Siemens, called Ellemtel) with 500 other developers. At the end of the project, fully half the code delivered was his. Since then he wrote an operating system; every time you make a cell phone call in Europe, you're billed by a machine running his code. He's humble about it, though, because he knows somebody who codes ten times faster than he does, and wears out two keyboards per year. Somebody five times better than average is barely a blip.

That said, it doesn't matter so much how good the Perl coder you hire may be, because when he's done all you've got is Perl code. No IHOP can hire a great chef, and nobody would notice if they did.

[Dan Murphy]

IMHO, good developers are motivated by: (1) interesting work to do, (2) good colleagues to do it with, and (3) compensation commensurate with contribution, in that order. On point 2, we use the test (C/A > 1.0), where C is competence and A is arrogance, as a great short-hand screen. You can't just hire the smart ones...a collection of egotistical prima donnas doesn't get much work done, either. If you hire raw talent, expertise will follow quick enough.

[Ben Smith]

There are some good points here. However, in addition to expert programmers, something that I find is often overlooked in software development is managers who are competent to make software development decisions. You can have excellent programmers (granted you probably won't if your managers are terrible) but if the person making the ultimate decisions doesn't have a clue what those decisions mean, then you're not going to produce very good software.
I have been surprised more than once to find that the person making the important decisions about software has little or no knowledge of good software development practices, or even of more general computer technologies (i.e. the difference between the web browser and the web server).
It appears that this is less true in other fields, such as bio-tech or engineering (the physical kind).

[Scotty C]

When selling high-priced proprietary software, sales people are definitely not interchangeable. As a developer-turned-sales-guy I can appreciate both the art of expert developers and the skill required to help a client see how a piece of technology can improve on "what ain't broke". Putting an egocentric sales person in the seat can be, in my experience, even more devastating to the bottom line than hiring a distracting junior programmer. But there's no question, I would rather have 3 Picards over and army of Wesley Crushers.

[ryaninfinite]

In regards to the Apple and Microsoft, I'm not so sure the issue with Microsoft is the developers as it is the manangement and the at times poisoness structure of that company (reading MS blogs you can pick up on such things).

Plus there are ( a few) examples of great products at Microsoft that solved difficult problems well and far better than anyone else had done up to that point, and there are some examples of lackluster Apple prodcuts.

It's quite enjoyable to poke fun at Microsoft but I really held myself back until I was willing to look at what they do correctly and learn from it, this otherwise excellent article helps contribute to that all to familiar religious war I tire of seeing.

[The Saj]

Rag on the sales all you want...

:)

That's not to say that sales are necessary, just merely that they deserve some ragging on. Simply because they are the tail end of the whole process "sales" people tend to get most of the perks and the rewards. Sales people would not have a job if developers weren't making a product. Developers could still have a need without a sales team if the product itself is necessary. Obviously though, one is only reaping a minimal harvest without a sales team. But sales people receive a disproportionate reaping of perks.

My mom works for a subsidiary of D&B. Her company had a good year. Her department which makes the product got lunch. The sales team got sent on a cruise. Likewise, I am a developer and work for a company with a large amount of sales people. But us developers don't receive the 1/2 day off if we get a lot of lines of code done in a given week. We don't see the bonuses or perks that sales people recurringly receive.

So feel free to give them a little ragging on. We're not dismissing their necessity - just the workplace's tendency to only reward sales people and not the rest of the people who make it all happen.

;-)

[Ryan]

I think you have oversimplified 'expert' and 'average' programmers. I agree that for the most part the best programmers I have had the pleasure of working with have experience in multiple languages and understand the fundamentals of programming more than any given language ( not to say they don't know the language they are using at the time ).

I think companies should look more to their developers for guidance in how the software should be presented and utilized rather than having sales or even marketing hands digging into the layout. Giving a programmer the ability to mold his sculpture is excellent. Stay away from letting others come in and tell them how the sculpture should turn out.

[Joe Blow]

I'll only disagree with 2 things:

1. To hire someone who has been doing something else and train them, especially in programming is truly cheap.
2. The right tool for the right job. Obviously Perl can do some things better than other languages, but to consider
Perl good for everything is just plain egotistic.

Most everything else I'll agree with, mind you the article as a whole completely dismisses the free market.
Corporations will always pay less, plain and simple. And most of the time pay more to "kiss ass" drones.
I'm coming from the free market side, it's much harder work, higher paying, and just plain enjoyable :)

Do a job search for cryin out loud.

Perl 5000+ jobs
Java 16000+ jobs
Guess what I write bank apps, engineering apps, gps, data analyzing, military, etc... and yes web apps in?

Later

[Foobar]

I disagree with the premise of this article. This article assumes that it's easy to determine who is and who isn't a good programmer and then goes on to discuss the benefits of choosing a good programmer over an average programmer... I find this discussion meritless because it's first assumption is, in my view, plain wrong. It's difficult to hire good to great programmers because generally, it is virtually impossible to determine how good a programmer really is based on an interview, a resume, the person's current salary at his/her existing job, or references. It is this fact that it's so hard to tell who is good and who is not that makes hiring difficult. Hence, you get the statistical mix of good and bad programmers after you've hired enough people. If it was easy to determine the quality of each programmer, don't you think everyone would prefer to hire the better programmer? Hence, I think the rest of your article is rather moot. Maybe a more interesting article would be an exploration of how we can reduce the costs of trying to figure out who is good and who is average to assist those who are in the market to hire programmers.

[Matt]

One funny thing you miss - hiring expert java developers is no easier. In other words, just because you can swing a cat and hit a java developer doesn't mean that they are any good. In fact, the problem is that you can spend a lot more time trying to figure out who to hire when trying to hire java guys, as there are just so many people to interview. The real trick is coming up with a good enough interview process such that you only end up with the best.

[Rob Phillips]

Now we just have to find a way to get the Alpha type expert programmers to play well together.

[Christopher]

I'm a former systems administrator who went back to school to get a degree in mathematics. I'd like to use it to do computer programming, especially for math-based applications. The trouble is, I have only classroom experience in programming, and little at that since I was busy learning deep mathematics. Thus far, I feel like the opportunity to become an expert isn't there just because the first thing companies balk at is my paucity of direct programming experience. Maybe right out the door an expert programmer would be 10 or 100 times as productive, but people with entry-level skills still need a place to start becoming experts. How does the high cost of low quality compare to the potential for making a high return by taking a bet on a promising beginner?

[John Q Programmer]

This article is right on. With one exception to the rule though. I consider myself to be one of those good programmers, and having done many interviews trying to find additional good programmers for the company, I know how hard that can be.

Having said that, I find that taking on smart kids straight out of school that have a good handle on programming and mentoring them closely, you can actually "create" new good programmers. So long as they want to learn and are interested in programming and developing their careers, I find you can often mold them into the programmer you need, that overtime actually creates good code. From the get go, teaching and enforcing good habits from the start of their career can make a huge difference.

[Don]

It's not just money or how careful you are in hiring. It is also how important quality work is for the business. Good programmers/engineers are created not born. It takes a lot of experience, study, and work to become excellent. The question I have is, what is most important to you, quality or schedule? Throughout virtually all of my career, the organizations I have worked for have made it clear that they value schedule over everything else and they will not work to train or enhance employees skills. Even discussion of how to improve is frowned upon. I can not count the number of times that managers have come to me to ask how long a project is going to take. I say 6 months (or whatever seems reasonable) and the predictable reply is 'What would we have to do to get it done in half that time?' 'Well, I can throw some crap together, forget documentation, forget most of the testing and hope it works; is that what you want?' 'What ever it takes, we just have to have it ready in 3 months or we will lose a tremendous amount of revenue.' So I do as asked, throw some junk together to get it out ASAP all the while hating myself for doing what I know is just shameful work. And often as not, 3 months after I turn it over, I ask how that project is working out and get the reply, 'Oh! we're still waiting on approval to put it in production. Management is still negotiating which division is going to run it.'

Companies don't get high quality programmers/code because they don't cultivate it or understand what it is. Companies get what they set as their goals. If excellence is what they strive for, they will get excellent programmers.

[Frank]

Programmers being artists - That is a true statement. I have seen some great code coming from artist-programmers. Code that was efficient, and for the most part bug free. My company was too stupid to try to keep the really great programmers. They preferred to hire 2-3 average joes to replace the really good person they drove off.

[DDT]

There is just a hidden problem with your approach.
The subtle difference between "Expert" and "Superstar".
WARNING: The Superstar looks like a great "Expert" even to a good HR department. And he will be hired.

The Superstar has his tools.
The Superstar has his code-indentation.
The Superstar creates his own template class to represent an ASCII char.
The Superstar uses UML to study his Char class.
The Superstar writes 10 lines of comments for the "Char Char::toLowercase()" function.
The Superstar blames anything/anyone not being like he is.
The Superstar refuses to code in Perl since Java is more OO.
The Superstar rewrites perfectly working code because it does not use the latest funky tech.
The Superstar is an artist and he writes complex code no one else can maintain.
The Superstar is INFECTIVE and will spread his religion amongst other developers.
The Superstar you want to avoid like pest.

P.S. Programmers are no artists. Art is not rational. Feel free to flame me ;)

[Programmer]

Companies and hiring manager and every one else loves to talk about the product and whine about poor programmers out there etc.
Problem with programming is that they are never trained after they graduate. I am a Java programmer so all I know about is Java in this regard. How many people are sent out for training on Spring, EJB or AJAX JSF?
On the other hand managers go for training to
learn PMP crap? Desktop Admins are being trained at WIndows Vista............
And programmers are never given a good orientation they must have in a company to have a good start. People see a website or application all of a sudden they want ur programmer to imitate that or integrate with that ..........

[Christian Bongiorno]

Ultimately, you will get that guy who says: "but I don't want the Cadillac". And in fact, there is a market for substandard software as there is a market for all non-ipods. Inherently software is something people can't get their head around. It kinda doesn't exist but does. If 'his' Dell blew up, you can bet he would be on the horn with Dell and mad as hell. If Windows crashes, or Word loses his document, he will be on the phone with Dell.

[anonymous coward]

Smart guys who are paid less, simply work two jobs. One for their
employer with their head, and one for themselves with their heart.
Guess which one gets the most awesome design/dev work...

At my company, the java developers are paid around $80K, so they
all have other gigs. The management knows it. The developers know they're
not getting ownership, only a job (just over broke).

I believe if mgmt treated developers as partners, in pay and ownership,
small businesses would accomplish an order of magnitude more than they currently do.

Perl,PHP,Rails and the other script-kiddy languages are
great for cranking out prototypes. I'd think twice about using them
for a real production app of any size and complexity.

Creating clean code means continuously refactoring it to
eliminate redundancy, make it more intuitive, reuseable etc. This is
too much mindless work for lazy-smart programmers without IDEs
to do the refactoring.

[Paul Gee]

"An expert can easily cross over from being a novice in any language in a matter of a few weeks" !
What a load of a rubbish.
Anyone who crosses over to a new language in a few weeks still going to be a novice. And anyone who hasn't used a language in a few years is going to take at least a few months to get back to speed.

An real expert programmer has specialized his/her skills in one language and knows very well which APIs, open source libraries/frameworks and code from their previous projects they can use to build applications well and quickly.

[Dave]

"...but sometimes money isn't enough to keep good people."

It doesn't hurt though.
I think that the main point here isn't base salary, but relative salary. That is, how much more do you pay someone that's exceptional vs someone that is just average?

I've worked with people that can do in an afternoon what takes others a month; but, when it comes to compensation, you might see a 10% difference in salary. Paying the exceptional developer more helps a lot. However it's not just because they have more money in their pocket when they go home. It's also important to demonstrate to the employee that they are valued for the work that they do.

[Donovan]

I agree with most of this except for the Perl and the apple comments. Perl is so 1999. And apple is so 1989.

[Paulo Cortes]

I agree with most of the article, with the exeption of perl, and with the
statement about "experts are lazy". I consider myself an expert with well
earned PhD and, also knowing many other experts" I can tell we are not lazy.
An expert is also the person who stays until the job gets done, you never
become and expert being lazy. Also, kudos to python.

[Tim Armstrong]

I realise this is non-Perl centric. But ask if they own a copy of "Effective C++" by Scott Myers or "Effective Java Programming" by Joshua Bloch. Ask them to bring it to the interview, if its well thumbed with lots of PostIt notes hire them, they probably care about their craft. Also ask left field questions like how would you crash a JVM, an expert can probably think of several ways to do this offhand. I'm sure there are Perl equivalents.

[David]

Good programmers are much harder to find then good sales people.
With decent training an average salesman can become quite good.

With decent training an average programmer will be... average.

[wim]

yes, the somewhat extrinsic apple plug at the end kind of spoils an otherwise excellent article :(

[Oleg]

What you describe is not an expert developer -- it is just an intelligent person. The criteria could be applied to any field of work, research, life or polytics -- to life in general. The sad thuth, however, is that more often than not people who hire in industry or make decisions in polytics are *not* that intelligent as a person you describe. However bad the IQ test can be in general, it will do for a simple comparison: you describe a person with an IQ of 140+ (98% percentile) and decision makers have about 100 (average) in many cases. It is simply pointless to try and prove them that it is worthy to pay intelligent people rather than the "qualified-on-paper" ones. Talking of HR it is even worse: you will first have difficulties to prove them that they should consider a Java developer for a Perl role, I do not even say hire him/her. The CV will be sorted out by a robot with IQ of 0 before it will then go to the hands of an HR guy with IQ of 80 and only then it will maybe endup in the hands of a manager with IQ of 100. By that time Perl must be in the CV, otherwise it is out. And why it is so bad?.. Because the overhelming majority of people everywhere on this Globe do not like to think (in general terms), do not know how to think and therefore can not be expected to hire a person who is supposed to think and not simply do a mechanistic job (and this is the one you describe).

[Auggie]

Interesting stuff here...however, I think with the pressure on most companies to maximize profit (and if the company is doing well, throughput), the reality is that it "seems" you can get more out of 10 developers than 5. Try counter-arguing that to a CEO that doesn't know Ctrl-C from Win-L. Also, expert primadonnas (err developers) can be a management nightmare.

So, as with all things in life, it's all about the balance. Just need enough experts to guide the sheep.

[Bill]

Sometime in the early 80s; Tom DeMarco and Edward Yourdon did some measurements of programmer productivity. They decided the productivity difference was 13:1, expert to novice.

Good post; maybe you should send it to HR departments.

All languages that are described are real; some are just more alive than others and some have better training wheels(static typing).

Would Microsoft really limit the number of buttons in the double digits?

[Dante Lorenso]

The article was going great until the last couple lines. I guessing that if I was buying the rest of the article, then I'm supposed to swallow the general attacks of "It is the difference between Apple and Microsoft. It's the difference between the iPod and a 400 disc CD changer with 50+ buttons." as having the same validity?

I mean, sure holding down the play button for an extended duration is akin to turning a something OFF!? What EXPERT thought that up? And PERL ... ahem? Ok, so I walk away with the new understanding that your definition of "expert" may not be the same as someone else and perhaps that is why your experts aren't getting 10x pay.

[Bill]

"Some of the best developers I know were originally trained as journalists, mathematicians, linguists, and other professions not normally associated with software development."

I'm glad that you've been lucky in that way, but that has not been my experience. I find that people who don't have a computer science background (or worse, self taught) are lacking in certain fundamentals. Like Data Structures or Operating Systems, for example. Maybe this isn't a problem for most perl jobs, but in the embedded software development shops where I work those are killer skills to have.

[David Emery]

I suspect one reason why PERL programmers cost more is that PERL is a -much more difficult- language to use effectively.

A core problem with this business is our willingness to use labor-intensive tools that require experts for effective use, both where such tools may be appropriate, and where they are not. Instead, we often use poor or at least labor-intensive tools everywhere, and then throw bodies at the problem.

From my perspective, any time I need to use a debugger, I see this as a personal failure as a programmer, as it's a sign that I don't know what my code is doing. I'd much rather try to get it right when writing the code (using languages like Eiffel or Ada that emphasize design-by-contract, strong type checking, etc) to find or better -prevent- bugs at compile-time, rather than spending painful hours in front of debuggers trying to fix problems.

But such approaches are clearly not in favor these days... sigh...

dave

[Anonymous Coward]

Fantastic article! Other than strongly disagreeing with the Perl portion which is totally biased....right tools for the right job...don't try to start another flame war (Or at least we leave it for another article ;).

Totally agree with everything else said. I work for an organisation that is totally commited to talent and paying for them. I can see the absolute difference in the work environment, the drive, the quality of people you work with. Its just feel fantastic to work with great people.

compare that to my previous job that has a low pay cap for developers....absolutely sucks....turn over rate was so high...architecture is crappy, code is atrocious...its also full of people resistent about change. Quality of people don't stay consistently bad....it gets worst and worst. All good developers leave soon enuf. Bad underachieving developers are kept for their loyalty (truth is that these people can't find a better job so they have to stay ... and they get rewarded as management thinks its easier to keep these people than some experts who's gonna leave them soon....guess why they leave so soon....). Everybody thinks its a fantastic place to go when you are thinking of retirement.

[Turtle]

I've watched this evolve for nearly 30 years. The danger in the IT business these days is managers who don't know what they're looking at and HR people who have no idea what they're hiring. As long as larger organizations hand IT job slots-to-be-filled off to HR clerks whose job is to go through resumes and highlight acronyms in green, and as long as managers ask dumbass questions like "where do you see yourself in five years," they'll get mediocre developers who talk a good game but leave wreckage behind. This article brings to mind the legendary Hacker FAQ: http://www.plethora.net/~seebs/faqs/hacker.html

Still a great article with immense truth in it. And when I hire somebody, that's what I keep in mind, mostly because I wish more people had taken it in mind when I was younger.

[mjr1007]

Interesting article, but you definitely got it wrong about the sales people. Worked pre-sales tech support with half a dozen different sales reps and the good ones could easily out do the poor ones by 5X. Not only do the good ones bring in more revenue but they also do it with fewer resources and time wasting sales calls. The saying around the office, borrowed from real estate, was “ the three most important things in sales is qualify, qualify, qualify.” The good ones did, the bad ones would drag you all over the place without a snowball's chance of closing the deal.

Like the comment about being an Admin in a different life. Have been both a Sys Admin and a DBA and it helps a lot.

One thing you missed is an experts ability to switch between development environments. Once did 5 different development environments in a single day, Informatica, SQL, KSH, C & AWK. All the programs were ones the client's staff could not write. As you might have guessed I'm a hired gun.

[Datapimp]

I have to agree with most of what is said in this article, having experienced it myself. I managed a developer team consisting of 5 solid members for 6 years and guess what the result was... Happy users, No turnover(zero!!!), frequent releases, team members who were able to cover when others were on vacation, and a group that was more productive then a team of 50 in another part of the company.

And as their manager, I gave them whatever kept them happy. And thus the business grew.... 10 fold that is.. :-)

[Jason Pirkey]

This is a very good article. I think a company needs a range of developer skill levels, but having said that, needs to know where to use them. You let your expert programmers do the initial coding/design or whatever. Then it makes sense to hire the junior ones as tier 2 or 3 tech support as they can write test cases for bugs or even fix bugs (with expert approval of course).

[John Bokma]

"apart from being grotesquely wrong about Perl being an adequate language"

People who consider Perl not adequate have either never managed to go beyond maintaining a few badly written CGI programs - of which there are, like PHP programs, plenty available for free on the Internet - or have been using a hammer when the problem wasn't a nail.

I have been programming Perl professionally as a freelancer for over 12 years, and readable and maintainable programming in ANY LANGUAGE (I master a few besides Perl) require just that the programmer has not only skills to code, but also skills to keep it readable. Following a style guide, or agreeing on one with co-workers is with any language a must.

In short: language can't make you a messy coder, however incompetence will result in both bad and unreadable code. Something that looks like it's written in language /fill in the blanks/ doesn't mean it's good code, nor that it's readable.

I can recommend to grab yourself a copy of "Perl Best Practices" and take two to four weeks to study each piece of advice carefully Steve, unless you're happy with just trolling.

[Chris]

You had me on side till the 5th point, at which point you lost credibility.

[Peter Schoenster]

I'd agree with much of what you say except with your means of determining if a company has expert developers. The only place I've worked where change started at the bottom and worked up was on my own projects. I work at a company with a software development cycle where work begins in the business and works through project managers and analysts and finally to my cohorts and me. Development is more than just developers.

[newbieSEdev]

Hello
I am new to the field of software development...I just finished school with a BS in software engineering and am going into the job market. I have had a couple of 6 month co-ops, but didn't get great experiences at those companies and now feel like I have fallen behind my peers. I am wondering, how would you recommend that I work towards becoming an expert programmer. Please help...I want to work hard and be successful with a good job, but don't really know where to start. What can you suggest I do in the meantime while looking and what can I do at my first job (when I find it) to become a stronger programmer. I felt this would be a good place to ask because a lot of expert programming managers will probably read this article. Thanks for any assistance and I hope someone can help (even though this may not be an appropriate place to ask).

[Jim]

I couldn't agree more, especially with that last statement: "It is the difference between Apple and Microsoft." That difference is a philosophy of mine in just about everything that I do be it my job as a Java developer right now, my friendships, how I schedule my days, etc.

[Zubin Wadia]

We get criticized a lot for having a "haute codeur" attitude to developer hires, but it pays off in the end because of the points stated in this article.

In the world of outsourcing, we are going to see a shift from massive profits to attrition over the next decade. The players that survive will be the ones that have mastered the art of hiring good developers and keeping them engaged through their tenures.

The key to this mastery is identification of aptitude and pedigree. Once you have that, the next challenge is synthesizing this talent into productivity. Once this is achieved, the duration of their tenure in an organization is directly proportional to the degree of expression they are allowed.

Irrespective of geography: very few are good. The great are even rarer. Treasure them.

Shameless Plug: If you are good - click on my name and send us your resume! We'll value you.

[Joshua]

I don't think you can judge the quality of the developers by the quality of the end product. I've seen excellent code turned into crap products by poor management or outrageous marketing.

[A]

Good article. I can't say I agree with your stance on perl though... and it is ironic because in my opinion one of the marks of a junior developer is that they always have a golden hammer. Perl is great for certain things (text processing) but not for others (truly performance critical tasks). A great developer uses the right tool for the right job, they do not look for excuses to use their favorite technology.

[jmt]

Nicely done - and well written. Having bounced around five different companies doing sw development (military development in assembly, telecom in C and C++, development tools in Perl) I know that a good developer is worth his weight in gold. If you've got one, pay to keep him. It's easier than trying to replace him.

The thing many hiring managers tend to forget is that the dot com bust is over. There are no more hotshots out there serving coffee waiting for the market to pick backup. The market has picked back up and the good ones are gone. If you need a new developer, be prepared to pay for it - and not just salary; revisit Maslow.

[Chris]

You underestimate the difficulty of *identifying* expert programmers. I get a lot of resumes across my desk, and it's darned hard to tell the productive ones from the losers. If programmers came with a number tatooed on their forehead that showed how good they were it would be easy to pay more and get a lot more. But unfortunately there are a lot of developers who are skilled at writing resumes and doing interviews and little else.

[MarceloL]

While I defer to the esteemed Engineer from Kansas on his opinion about Perl programmers ( I call everyone's attention to the "Language Hierarchy" chart: http://blogs.msdn.com/blogfiles/steverowe/WindowsLiveWriter/ProgrammingLanguageHierarchy_1489F/programmer_hierarchy[7].gif ). So thusly they can become familiarized where Perl's "True" place in the order of things is. But I digress. On every other point I have to agree not only wholeheartedly, but EMPHATICALLY. Having returned to college, to pursue an MSCS. In part to prove to son and stepson that an old codger like me can do that, and part to prove it to myself ( and yes, to also get ahead, and stay competitive in the job market). The interesting thing is that when I find myself when dealing with mostly younger programmers than myself who've been indoctrinated in the ways of (oh heck, pick your favorite ) TLA, ( OOD, OOP, UML,MVC, MVP, yadda, yadda. Oh sorry that was 5 letters twice.) without the more pragmatic principals we were taught 20+ years ago, I really have to wonder. Then again, nowadays you've got rampant lunacy running the minds of "CIO'S" (when in the He%L did that mean something other than "Programming manager who couldn't program, so they sent him away to get an MBA" ). Let's outsource this and that to this company that 8000 miles away that uses "Engineers" who received their "Engineering education" in 14 weeks( Excuse me, I just looked up the link, it's 16 weeks ). http://www.australianit.news.com.au/story/0,24897,20042766-15322,00.html Sure, some of you will say, "The old guy's off his rocker, he's just spreading FUD". Fine, this "Elmer" will clean up all the "wabbit mess" left over in the aftermath of some silly accountants dream of saving beans making him look good to upper management. The bill is in the mail. Oh, and about the money. I agree, it's often not enough to retain skilled, professionals. Those same folks will tend to gravitate to organizations where the monetary rewards balance with other "non-monetary" benefits. What those "non-monetary" benefits might be, well, that's where your mileage will vary.

[Screw Perl]

haha Perl is THe language... you discredited yourself with that nonsense.

[DW]

100% agree !! Great staff, I wish my bosses would think the same way :-(
About the comments...
As always sales people missing the main point and destructing from the issue to something like... "just a second, let's talk about us". Calm down, guys this time its not about you. So seat back and agree just once for a change.

[Steve]

I agree with most of your comments. Expert generalists do better work in any language than narrowly skilled programmers.

[BlogReader]

I agree with the out of wackness of paying highly skilled devs only 20% more than the average one when they do produce a lot better work. However this article fails in that all the numbers are completely made up. 10x better? Source? Pay 5 perl devs $120k and you'll save money over 15 $60k java programmers? Why those numbers?

Also doesn't everyone think they are a highly skilled programmer and not average?

[isomer]

In my experience, a large part of the problem is that non-experts cannot recognize an expert when they see one. So the HR department or even a non-technical manager is unlikely to find the right person. As you allude to above, your chances of success are far higher if you ask your best guy to refer someone who's abilities he respects.

[Ryan Winter]

While I can understand the backlash about the sales comments, sales guy wasn't much better. Sales don't generate the revenue of a company, EVERY employee does. And if they aren't then they shouldn't be an employee. Engineering design the product, manufacturing build the product, sales sell the product, finance makes sure bills are paid on time, secretaries keep everyone organised, the cleaners make sure the building is in a state to be worked in... If any one part of this system fails, then the company will fail, or at least lose efficiency.

Overall I thought he article was quite interesting, ignore the obvious bias to Perl and Subversion (great products, but not necessarily the best in my opinion). However it does ignore reality. As mentioned, good programmers are a scarce resource, however if every company didn't settle for less than the best, then most companies just wouldn't get any work done (cause they can't find the people), and the salaries would skyrocket temporarily and then the entire IT industry would collapse.

Reality is that employer's accept what's available. Find the best employees, without artificially inflating wages by demanding no less than the best. At best they can hope to attract a number of excellent programmers and put them in lead positions.

[JT]

I can confirm this. I usually come in to clean up jobs that have been outsourced or given to the lowest bidder. The Dot-Bust created a mentality among companies that computer professionals are expendable yay-hoos that fix a problem and then go away.

After working for 13 years in IT and 3+ years in programming, I can see a correlation between people who have a knack for computers with the drive to study and high quality work. The juniors are kinda funny when they ask what "ping" is. I've found the best way to look at computer professionals is to think of the computer like a car. Sure, you can get any old kid to fill the tires with air, or even do it yourself. When you get your oil changed, you want someone with tools and a little intelligence. You might even do it yourself if you enjoy that or are hard-up.

Now suppose you have a Formula one race car at a championship race... Yeah, you want Linus Torvalds... hehe. I suppose the computer equivalent would be a corporate infrastructure for 2000 users. Now you know, if your top IT guy keeps 2000 systems running and you think you can hire an H1B visa holder from India to do the same job for half the price, think again.

As for India, basically a 4 year degree is like a trade school here. A one-two year certificate is like a week/weekend course here. Once you start getting people with PhDs and Masters from India you start getting some qualified people, but don't count on it. Usually the Indian equivalent of an American expert works for Microsoft for $60k/year(in India). I just laugh at companies now because they are destroying themselves from within. Perhaps one day they will wise up.

[Craig]

Very well said, thanks for taking the time to illustrate this. Echo to lofi's comment!

[Patrick]

I completely agree with a lot of this article. As a programmer myself, I just got into the management aspect in the past year and I have had a horrible time finding developers.

One thing I've noticed is having a kickass resume of several large companies is not NEARLY as valuable as actually being interested in what you do. I've had several developers who came from major companies with good credentials, but had little interest in programming or learning. Seems a lot of people choose the occupation because it pays well (or rather, people think it does :)) not because they have any interest in it as a job.

And location doesn't matter. While there are many more people on the highly skilled end, the vast majority of programmers in Silicon Valley are no better than programmers from the midwest, and they get paid a LOT more.

[Malderi]

Interesting especially because of the several (not many, but several) Apple API's I've worked with have universally sucked, with poor documentation and weird bugs. That's not to say Microsoft hasn't produced some pretty crappy libraries in their time, but if we're talking about developers here, putting Apple on a pedestal isn't the right way to go.

Perhaps expanding your examples to designers in general :-)

[Diltsman]

I have to agree with this article. I'm a 5th (or maybe 6th) year Mechanical Engineering student. I'm working as a C/C++ programmer, writing engineering software. I took over a project that my boss started, and then another guy did for a while. It was amazing. Those two guys were the best programmers where I work (yes, we are almost all interns). The code was impossible.

I'm a good programmer for a CS student, and a very good one for an ME student. It took me 2 weeks to rewrite the code to a point where it was even workable. It was amazing. I had to remove about 6 global variables (that never should have been there), move almost all of the code somewhere else, etc. But now it is good enough that you could at least figure it out without too much of a heartattack. Still, I'm sure that a good programmer would look at my work, and see about 1,000,000 to change, but I'll get there with experience.

[CodeSlave]

Nice to learn that other people also have thoughts like in the article.
Now I just need to find a company with such people...:-)

[Philip Callender]

To the author:
I don't know if you want to post this (you might consider it an attempt to advertise), but you might be interested in what we are doing. We've created an entire business around the principles you mention, with a multi-skilled, multi-technology, multi-country group of developers. Quality leads to a cheap development, whereas cheap developers do not. There's no substitute to getting it done right the first time. We're a relatively small group, but we get to work on great projects, travel to interesting countries, and have a huge amount of flexibility in our non-working lives - http://www.virtualsoftwarecompany.com. Cheers, Phil Callender (co-founder).

[Nilay Vaish]

I think almost all languages of a given paradigm are similar. Imperative ones like java, c, c++ or perl, functional languages like haskell, ML or logical languages like ProLog. One only needs to know a langauge from each of the paradigms well and she/he would be able to learn any existing language in no time.

[Martin]

Jimbo, you're right on track.
If an expert is 10x more productive, why can't companies pay at least 5x for them? (e.g. 500k instead of 100k) Because they are not close enough to the decision-making. I have found that the closer you are to making decisions that have a direct impact to revenue (e.g. sales, biz dev), the more "unreasonable" pay you can make.

Employment truly is a bad deal for someone who really is a hotshot: you are purchasing stability, at the cost of little risk for a much larger potential (even doing contracts you can work 6 months and make the same money, how much stability do you really need?).

[Mike]

"It is the difference between Apple and Microsoft."

You just discredited your entire article right there. You did yourself a disservice. You are not big enough to express you own independent thoughts, which are admittedly above some marginal level, without bringing yourself down to some idiotic level.

The big time developers such as myself--getting paid $200k+ a year--know that "Microsoft vs. Apple" has NOTHING to do with real results on mission critical, high consequence projects.

[sandeep]

Very interesting and infomatic. Realy usefull. Thank you...

[Sudar]

"Companies need to stop thinking about their developers as cogs in the machine. They are more akin to artists, authors, designers, architects, scientists, or CEOs."

Well said, all your points are valid and I totally agree with your thoughts.

Regards
Sudar

[sanjar]

Sales people, hr, programmers and even the cleaners of the office - should all work in tandem. And this tandem is organized by the managers.
Managers - are the core. I hate managers ;)

[Bryan]

Lovely article. I've been on all sides of the issue. I'm now stuck on the worst side -- I've spent three years trying to hire a semi-decent Perl & JavaScript programmer to assist & take-over my programming so I can better run my small business. I've gone through five individuals who have made it through an increasingly rugged interview only to wind up producing code that is more of a liability than an asset. The type of code that may work perfectly, but cannot have any features added without blowing chunks. Granted, I can't manage humans for my life, but I'm still hoping to find someone with the passion to be capable of seeing the future without being told what it is -- something that I do each and every day.

Can't agree with you about Perl. I love to hack and have for nearly three decades now but perl still turns my stomach. Python, Ruby and especially Lisp are much more to my liking.

That aside the big difference to a hacker is how much BS is in the way. The BS takes many forms, endless meetings, office politics, getting the approval of a manager who think he (usually) know enough to vet the hacker's ideas, BS that says all success is due to "the team" and only gives individual recognition for insane number of hours worked or throwing chunks of your life away whenever a "higher up" gets nervous and wants to see extra sweat inequity to feel better.

What is up with the telecommuting thing? I couldn't agree more. Except for meetings (mostly worthless) and bonding with a few folks I don't get the point of moving the flesh to a particular locale before I can use my mind. It is utterly stupid. Drive an hour each way in prime hacking and idea time to arrive sour and a bit teed off to the first meeting of the day leading into questions that somehow get answered otherwise if you aren't there leading to a bit of monkey interaction and then lunch, a few more hours of countless interruptions of real work and then back into the tin box for the mind numbing right home. Is it any wonder that most corporate software is a piece of krap unless someone laid up or using all their non-office time designed and la