Jeff Atwood quotes an interview with David Parnas in his most recent blog post.
Q: What is the most often-overlooked risk in software engineering?
A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.
I noticed that too. It’s a fascinating observation, and quite true. It also plays on the latent idea that jobs are an absolute good, which is not so.
That is SO true! Even adding good programmers to a job slows down progress initially, especially if they are from outside. You need to show them everything from how to log on to your particular system to the location and structure of the data sources, not to mention the desired outcomes, logic, etc.
Bad programmers tend to hide on teams where it is difficult to identify individual contributions.
I have found the easiest way to identify good programmers is to ask them to show me something they have written and explain how it works. Good programmers usually have several things they have done that they think are particularly cool and want to point out to you in great detail why they did X and it was particularly clever or used a new feature of the latest release of the language / OS .
Bad programmers talk in generalities about the project.
Some time ago I had drinks with a few Silicon Valley engineers; the ones in their 30s were decrying the lack of ability of current graduates in EECS. The oldest one (mid-50s) considered that an opportunity: incompetence of the entering class meant guaranteed jobs for people whose training and experience gave them superior competence.