I use 'hess' to find all the email addresses of their company that I can possibly find on their website and start emailing all their employees every few minutes using a little script and a cron job.
Jokes aside, the article attributes characteristics and assigns blame to people based only on under/over designing.
It's well known that the same person can thrive with the right company/team/project/manager and produce good code and do terribly in the wrong one e.g. due to stress, and so on.
It's a totally shallow classification. Slower and Faster are relative terms, curious is a relative thing, energy is a relative thing. The problem is that engineers create these generic "boxes", place their staff in it, and divvy out work/rewards/responsibilities based on it. It's just like designing an object oriented framework. Your original classes are probably not quite right.
The problem is your boxes are almost certainly overly generic. You might say Joe is just a slow developer, put him in that box and move on. Maybe you talk to Joe, and he doesn't quite tell you exactly why he's slow... he might not know why. You have to dig deeper into it. Maybe he has weaknesses he is afraid to tell. For example, he might be slow because he has 10 years of doing C++, and now he's on a Node.JS team. All his prior knowledge is nearly obsolete. Maybe he's slow because he's not interested in tech problems, instead he's more interested in learning the domain... so he's just not motivated to work fast. Maybe he's slow because he wants to move up in his career, but there's no clear path where that is possible. Maybe he's slow because he has a new born baby, and he doesn't sleep at night.
If you just put him in a box, you're not going to work to try and find his strengths, and play to them, you're not going to work with him to find solutions. It is YOUR job as manager to learn what makes up your team as individuals, and to help them grow. If you just put him in a "box" you're going to call him weak, and your team will work at a crippled pace.
Your comment is unnecessarily combative, so i'm not going to further explain myself. The issue with your line of reasoning is that your analogy doesn't hold up. An engineering team building a product is not a rat race.
Maybe you are unaware, but the term "rat race" is a colloquial expression that is used to describe the type of situation that many office workers are in:
You can (possibly) categorize a person on a given single dimension in isolation at a time. But a person in the real world is the sum of countless dimensions, and the subset of dimensions that factor into a given decision or interaction is complex and fluid and effectively unpredictable.
