The 5th grade thing was just a label. You don't have to agree with my broad generalization.
ISTJ - The Duty Fulfillers (Data Analysts/Code Monkeys)
ESTJ - The Guardians (Sysadmins)
ISFJ - The Nurturers (Devops/Builders)
ESFJ - The Caregivers (Devops)
ISTP - The Mechanics (Code Monkeys)
ESTP - The Doers (Builders)
ESFP - The Performers (Builders)
ISFP - The Artists (Hackers)
ENTJ - The Executives (Sysadmins)
INTJ - The Scientists (Hackers)
ENTP - The Visionaries (Architects)
INTP - The Thinkers (Architects/Builders)
ENFJ - The Givers (Data Analysts)
INFJ - The Protectors (Sysadmins/Devops)
ENFP - The Inspirers (Hackers/Builders)
INFP - The Idealists (Architects)
You do get the point. It is the function of making communicable and increasing integration-potential the data to higher cognitive modes of thought (Folk Thought). The simpler your model, the greater the difficulty of exposing its rules to the audience. Generally, it's about "constructivistic myth-building". I'm not claiming Jung is the Law, and systems always stand in need of refactor (Quine's talk on the Ship of Theseus).
High Extraversion Programmer versus Low Openness Programmer. High Extraversion Hacker versus Low Agreeableness Architect, etc. Reductionism abounds.
I don't think it is useful to teach people that personality is a set of labels. We all have a intuitive understanding of personality, which is much deeper and gives a more nuanced picture.
Giver Data Analysts
If you use the First Term, or the Archetype Predicate, as a Qualifier to the Second Term, or the Programmer Type/Subject, you get 21. I rushed through this, so I'm probably missing Programmer Types.
Be constructive. Do the rest yourself.
I definitely fall under this type of programmer. Started learning Logo at 9 years old, Pascal from 10 onward. Worked part-time in high school as a web developer, worked a lot as a CS undergrad.
But I most certainly didn't breeze through my CS education. In fact I flunked out. Hell, I almost flunked out of high school as well because I spent so much time coding.
 I have two exams and a thesis to go, but at this point it's doubtful I'll ever bother.
I think it's more that we don't like taking the Intro to CS class, and either suffer through it or flunk out.
There are great coders out there who took longer than a year to code, but haven't coded since birth. I wouldn't expect someone trying to code while working a full-time job, or raising a new-born child, to get up to speed as quickly as a single computer science college student. That doesn't mean the former has less aptitude, or grit.
The article is a fun read, but doesn't make that sound a case for the existence of this "uncanny valley" class of programmers.
Actualy it is a hard questions to answer and every programmer is retrospective on there own code to the stage that they deem there first efforts bad. It is when they blindly impose those raising standards on somebody just starting out or not as far along as if they should be at the same level. They deem that person a bad programmer though it does not make them one.
Also programmers these days are doing more analysis and design impact roles than programmers of the past. Go to a old 70's enviroment and outside the ediucation/lab enviroments you had analysts and programmers with the written or unwritten rule that the analyst would have somebody else do the code from there program design. You had levels of anylysts and buisness experts going up the design project tree with the coding skills peatering of, even if they were only needed at the programmer level.
So that in mind i would say there are no bad programmers beyond those who can't program/know the language they are using and its quirks and pitfulls. Though there are bad analysts and a bad or not as well thought out design/approach can make the code bad. Anybody can hit vi and bash out code and design on the fly, though extremly rare to find somebody who can do that and nail the design of the bat. Good design takes time and nobody is perfect or we would just release 1.0 software and that would be all we would need to write.
Put this another way, how many of you have written more than a page of virgin code and it has compiled with no errors or warnings. Then it has tested out with no errors first time as well. If the answer is no everytime then are you a bad programmer because you made a mistake.
So with that what makes a good programmer. Well one that thinks things thru, gets the results on time or ahead of time and can alert to pitfulls that whilst not day one impacting would be a issue down the line and can be addressed before they become an issue. One who writes code that documents itself it is that well desigened and laid out in a way that makes it feel natural. There again a company that has a coding standard that has been solid as long as the code base does also help.
I guess you could also say there are no bad programmers, just lots of bad code waiting to be discovered. With that look back at the earliest code you ever wrote and ask yourself if you would not change a thing now. Did that make you a bad programmer back then even though you were not.
I'd like to extend your ideas a little and make the point that:
1) When you combine the two extremes of programmers you can get more than just harmony, you can gain synergy, and
2) As "new-found learner" I believe that the idea of 'good programming' can be abstracted to be 'good creative problem solving and communication.'
About the first point:
As I said I fall in the "new-found learner" category, for my start-up I've been fortunate enough to have a 'veteran' developer on my team who is astounding. Every time I watch him code or he explains the architecture I learn something new and useful. Best of all, we have a high synchronization ratio.
However even though he's been working for nearly 10 years as a developer for some of the best financial institutions in the world it's clear that he doesn't have the entrepreneurial thought patterns necessary to gestate and birth a start-up. The other day we were talking about this very thing and he's said that he's tried, and with others just like him, to dream up the next big "Facebook" opportunity, yet inspiration keeps eluding him. He told me a 'cautionary tale' about a colleague who quit his job to start-up a Golf Scorecard mobile app which got funding and then later tanked. From what he said to me it seemed that this newbie entrepreneur had no intimate knowledge of the the customer's needs, too much customer inertia and not enough market pull. I would be so bold as to say it over engineered the problem. These issues seemed obvious to me, but only through the lens of my own entrepreneurial experience... gained the hard way.
The point is that the "new-found learner" probably comes from a place where their life experiences add a 'je ne sais quoi' to the mix when combined with the technical experience of your "5th grade coders". This makes for synergy.
About the second point:
I'm absolutely certain that the time I spent as a finance and economics consultant has been applicable to my approach to programming. Why? Well I was lucky enough to be taught how to logically 'think' my way to an optimal client solution and how to communicate the solution in the clearest possible way. I would roughly call it the "McKinsey's Approach To Problem-Solving." When I say that I mean approaches like 'understanding the question', 'hypothesis driven solutions', 'issue trees', 'mutually exclusive and collectively exhaustive (MECE)', and the '80/20 solution search.' Looking back I'm certain that what set the consultancy I worked for and the others was the ability to communicate the solutions. Often economic or financial questions have complex answers. Even if the answer is simple it is often put forward in a complex way. By taking complex ideas and putting them forward in an simple way, and keeping simple ideas simple, the consultancy was extremely effective and profitable. The secret to this effective communication was our Plain English approach to writing. The CEO of the consultancy was fanatical about it, even to the point of reviewing as many client reports before they were delivered.
I find that by adapting these problem solving 'thinking patterns' to my programming, while keeping in mind that I need to communicate clearly I'm at least productive enough to keep up with the "5th grade coder" in my team.