Please excuse my laziness, but I simply don't have time to respond to each and every person who has E-mailed or left comments on digg, reddit, or the original post itself. I would like to respond to a few of the larger themes I've seen in the questions/responses:
This applies to more than just programming
I definitely agree that this can be applied to nearly any type of job, not just programming. A great designer is worth much more than an average one. And I honestly wasn't trying to single out sales and customer service people. I do agree that a great sales person or customer service rep is worth more than the average, and should be paid accordingly. And yes every employee is important to the company.
Using customer service as an example, I've worked with the worst where they would literally scream at the customer on the phone to the best. The problem with customer service is that the metrics are against them in that even the best customer service person can only take a few more calls/tickets than the worst. Just because of the nature of the interactions. It is also very difficult to measure if this person has pleased/retained more customers than another. With programming it is often easier to see how an individuals contributions impact the whole project.
Sales is a different monster, but hopefully this has cleared up what I was trying to express.
Only experts?
Do I think it's reasonable to hire only experts? Yes, in many situations a company can and should staff themselves with the vast majority being experts. Is it possible for larger companies with larger products? Probably not. If the problem simply demands 50 developers, it would be difficult to staff that entirely with experts. However, I do believe they would see a boost if they were able to have at least 10-15 of those developers be experts. Instead most companies have 1-3 experts that lead the team of the masses.
If you can't find experts, you should attempt to hire staff that could become experts over time as they gain experience.
How do you become an expert?
Everyone is correct in saying that experts started out as novices, I was certainly a novice. In many ways I still am. Being personally interested in martial arts I remember a story of someone, after years of training, finally receiving their black belt in Aikido and being told, " Now you are ready to learn." I believe this is true of programming, technology, and most professions. The learning doesn't and shouldn't stop.
So how can you become an expert? I think the best advice I can give is to read up as much as possible on your field. You don't become an expert simply repeating what you did yesterday for many years until, poof, you're an expert. You need to be learning new idioms, patterns, and tips from your peers.
Too many developers sit in their cubes and pound out code and never look up. You need to be reading up on your profession as much as possible, exploring new languages/tools to determine if you could be doing something easier or better.
An example of what I see far too often happened again recently at OSCON. A professional Python developer did not know Django was the predominant web framework for that language. I'm not a Python user, but even I know this. Maybe it's because I'm friends with the core Django team, but even if that had not been the case I would at least be aware of it and in general what it was from my day to day tech reading.
The other advice I would give is to read and become involved in an Open Source project. This improves your code quality and allows you to see how other, presumably senior, developers work. Even if you aren't able to contribute to the project directly, get on the mailing lists and examine how those developers work.
How do you find and hire experts?
I think the biggest mistake managers make is leaving this up to HR. I've always made sure I received every resume that came in for a position I was hiring for. HR will often reject a candidate because their resume states they have "Years of J2EE experience", but since it's a Java programming position it goes in the trash. Perhaps it is time we start hiring "HR Engineers" like we have "Sales Engineers."
The first place I look when hiring programmers is the Open Source community. If they are involved in an Open Source project you can easily see how they work with others on the mailing lists, see examples of their code, etc.
They also tend to be of higher quality because Open Source is a meritocracy. Not to mention the simple act of being involved in a project, for no monetary gain, shows a strong love of their craft.
I think multiple choice tests are a very poor indicator of programming prowess. Too often they have a couple of esoteric or even trick questions that really compare the test writers ability to confuse with the test takers' ability to decipher. It is much more important for your new hire to know how to find the answer than it is for him to actually have it tucked away in a brain cell. Ability to effectively use Google to search for the answer is much more important than many realize.
If you happen to be one of the people who are looking for an expert Perl programmer I suggest you get in touch with my new friend Uri Guttman, The Perl Hunter, at uri@perloncall.com. He specializes in finding execellent Perl programmers for companies. Being an accomplished developer himself he easily separates the wheat from the chaff and can find someone who will be a good overall fit for your organization.
Many problems are marketing and management's fault...
This is also very true. Bad management will bring down any team or project, no matter how many experts they have on staff. This isn't even restricted to technology management.
Marketing often over promises what can be delivered and demands it in an unreasonable time frame. Unfortunately most of the time we blame the developers, because long after the sale all that we see is the code and not the brochure.
My advice to marketing and management is that you bring a problem to your developers and then base your plans on when they believe they can deliver the solution. Far too often management has already determined time lines and set things in motion before the development team has even been told about the project. This is backwards. You don't schedule your building contractors before you have the proper permits or before even speaking with the architect about the project.
Even Microsoft gets this right. They realized it was much better to delay Vista until it is ready than to ship it too early just because they originally said a certain date.
Obviously you can't always just wait around for something to be perfect. There are always restrictions and requirements that are outside of your control. No one could move January 1st, 2000 out a few more weeks just because their Y2K cleanup wasn't done. But often I see companies attempt to move mountains to hit some arbitrary date when one of the largest consequences of delaying would be everyone had to update their Outlook calendars.
My language bias
I received a bunch of comments on my use of "Perl vs Java" in the example, that simply was what we were talking about at dinner that night. I probably should have used "agile language X vs cumbersome language Y" to keep the flames down to a minimum.
You can write efficient, readable, and maintainable Perl. I've even had some notable Python programmers say that about code I was in charge of and honestly the code in question wasn't what I would consider the best of the best. I think Python is a great language, but for me personally I haven't been shown any compelling reason to switch.
You can write crappy unreadable code in any language. You can make most any language/framework/toolset scale and perform to your needs. For every "large app/website/etc" that uses language X I'm sure I can find you a comparable app/website using language Y. Any performance differences between language X and Y can usually be solved with $100 worth of extra CPU. What really matters is programmer efficiency. That is where you save money and reap benefits. I simply don't see how having to write, read, troubleshoot, and maintain 10x the number of lines of code is an efficient use of the programmer's time.
However, I do agree that you should use the right tool for the right job. Java/C++/C# are definitely the right tools in many situations. I just feel that because everyone has seen a horribly written Perl CGI ( or written one themselves ) they think this is somehow ingrained in the language and because of this Perl simply isn't an option for anything "real."
Perl is a language where the developer must use some self-control rather than having it imposed on him by his tool. Which is why Perl (or many of the more agile languages such as PHP/Python/etc) written by novice programmers is so awful. The knowledge and self-control comes with experience.
The largest problem with any language is the use of poor variable, function, class, and method names. Using adequately long and descriptive names is probably the single best way to improve code quality and no language out there enforces this. Some enforce a certain style, others force certain methodologies, but this is really only picking at less important aspects of the problem.
Company bias
By comparing Apple vs Microsoft I wasn't really singling out their development staffs. I'm sure their management, design, and marketing departments are as much to blame for any successes or failures these companies have.
What I was trying to get across was the "It simply works." I would say the second most common comment I hear from Mac users, after how pretty/well designed they are, is that it "just works." I don't hear that very often from Microsoft users.
