A sub-category I find is the "scientist" programmer vs the "engineer" programmer. With the scientist programmer being these category-three people. An engineer will use existing frameworks, technology, standards, etc. to solve a problem. And a scientist wants to develop new frameworks, technology, standards, etc. to solve a problem.

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

I think there are some infamous examples from the old days of Microsoft. Think of the programmer who insists on using an obscure dialect of Lisp because of all the "clever" things they can do in it. Even if they work, and are genuinely clever, it can be a huge pain for the less brilliant/obsessed people to interact with.

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

John X is assigned to project Y with team A but find it very boring for him. So he overengineers in a way so that it only works by solving a very complicated engineering problem that he wants to solve instead (think "developing your own distributed no-sql db" class overengineering).

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?

Often, smart people seek challenges and complexity. This can be dangerous in software engineering, if left unchecked.