Actually doesn't your experience hint at the opposite trend in the working sector?
If everyone (roughly) either fails programming, or aces it, then the working professionals are the ones who passed AND excelled.
If everyone (roughly) either fails programming, or aces it, then the working professionals are the ones who passed AND excelled.
There is an amazing bit though: there are the ones that you classify as "surely worthless", but then you see they can indeed get some jobs done, so a non-technical manager or HR-person can easily confuse one of those that "can sometimes program computers to do useful stuff or keep things running" vs someone who can do "software engineering".
Oh, and then there's the infuriating third category of those extreeemly smart (IQ through the roof + wealth of knowledge) but extreeeemly unproductive (like even manifesting "negative productivity" and dragging a team down or an entire project into the ground, the "-10x programmer").
People are... complex :)
In general, this seems to be a problem that arises when smart, capable people (who are short on common sense and teamwork) become so valuable that they get to call shots no one else can accommodate.
Imagine Mel being on a team of 15 people: http://www.catb.org/jargon/html/story-of-mel.html
People who don't get this are really the worst to work with.
On larger teams, you want some commonality with your code. You want to be able to look at code written by others and at least have common style, strategy, and idioms. Engineering style devs tend to follow this nicely and it all works fairly well in a team dynamic. Whereas, scientist developers are often looking for new ways to do everything. When they see things done in a common and consistent way, they tend to look for unique solutions and tend to do more of "research" style development.
Don't get me wrong, both styles have their benefits. But on a typical largish development team, the scientist are often a more negatively-impacting developer to the overall productivity of the team.
The really scary thing happens when these scientist type developers become architects. And then you end up with what is often called an "architecture astronaut".
John X leaves for a more interesting project, team A can't make modifications to the current over-engineered system so they need do a rewrite of a few key components that incurs a huge delay.
And yes, it was not John X's fault. It was the manager's who assigned it to the wrong team and project, and the team leader's that they didn't have working code review process to be able to give JX feedback early to "write code easier to maintain by a less experienced team even if it's maybe less efficient and takes him a bit longer".
So you're right in insinuating that category-three people don't really drag projects down: it happens when they are assigned to the wrong place and when you have teams with broken processes, so objectively speaking, bad management is actually what's dragging things down in this case. But isn't "bad management" close to a pleonasm anyway?
I've worked with people in the past who know just enough to hack together a front end on top of a simple database, but who would completely fall apart when presented with anything more complex than that. These are the sort of people who when asked to build an internationalised website "solve" the problem by copying an entire PHP application into directories called "english" and "german" and then proceed to change the text in the German version.
I think this is a big chunk of explaining how bad programming goes, too. It's not "too incompetent to build a thing", it's "incompetent enough that everything runs on voodoo and evil".
However, it is very easy to cheat your way through college and obtain good grades. My assessed coursework regularly shows up on rentacoder.com and similar. There is an industry out there for writing dissertations. Group work is another mechanism that weak programmers use to avoid getting better: they let the good programmers do all the programming and then do documentation, or UI design, or nothing. In addition, there is a pronounced grade inflation, so even weak students look great on paper.
Not every organisation has the know-how to filter out weak students that look great on paper.
One person I interviewed stood out in my mind for having completed a Master's in CS, was able to classify the problem I posed her as belonging to a certain type and told me how it should be approached. She still couldn't even begin to write the (simple) code to solve it, however.
This person was obviously smart, and also quite obviously had no programming skill.