A sub-category I find is the "scientist" programmer vs the "engineer" programmer. With the scientist programmer being these category-three people. An engineer w

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