Uneven distribution of skills and knowledge is a wrinkle that everybody has to grapple with in their careers. I think what the post is describing is programmer

Uneven distribution of skills and knowledge is a wrinkle that everybody has to grapple with in their careers. I think what the post is describing is programmers who have a fairly narrow vision in which their particular talents and knowledge take on disproportionate value. I think these programmers tend to be the happiest workers, and they tend to develop themselves to the fullest, because they are fueled by their outsized belief in the value of their particular skills. This can bring a great positive energy, but the downside is that they tend to turn into hero programmers and create codebases that are impossible for others to work effectively in, and they can sabotage the confidence of people around them. If they are so inclined, they can be very effective bullies, but even if they are nice people, if they really believe in the vital necessity of an ability they have that others don't, they won't appreciate the value of others' work. For example, being a prodigy at writing fast, low-level code is a good thing, but if you develop a blanket belief in the importance of code being extremely fast at a low level, you will mistrust and devalue code written by other members of your team. The more important the project, the more you'll feel that you need to write the important parts yourself. Your teammates will notice, in subtle or unsubtle ways, that you don't believe their code is good enough. You'll also fill the codebase with code that only you can properly maintain. Probably the most dangerous strength for this kind of programmer to embrace is their ability to handle a high degree of complexity. In almost any software engineering context, this will result in the generation of unnecessary complexity that one team member thrives in and other team members drown in. The opportunities to "improve" a codebase at the cost of a little additional complexity are infinite. Other team members' work will have far fewer of these improvements, and this will be painted in a negative light. When people argue against marginal improvements on the basis of added complexity, the hero programmer might feel that they are simply inferior programmers trying to devalue their talent out of jealousy. In short, working at the absolute limit of your greatest strength and foregrounding that in the work of your team is extremely fulfilling, but a great way to sabotage your team. At the opposite end of the spectrum are people who are too quick to write off their strengths as an unimportant part of a big whole. They are less happy, and more likely to plateau or even fall off in performance over their career, as their awareness broadens and their own self-assessment shrinks in proportion. When they come into an environment that is shaped by the talents of others, they might feel paralyzed and valueless, instead of believing that the team can and should change to take advantage of their skills as well. These programmers will chronically disappear and underperform. I think the ideal is not a happy medium between these extremes but rather a change in approach. Instead of foregrounding your strength in the work of the team, can you background it? If you're a performance expert, can you design an application so that others working on it only need to follow a few simple rules to maintain the high performance? Can you make it trivial for other programmers to check the performance impact of their code changes? Can you instrument the application so that performance issues can be quickly identified and diagnosed? Can you turn performance into something that other team members barely have to think about? This requires you to value other people not knowing what you know about performance, to see that as a cost savings. Instead of thinking, "My knowledge is valuable because I am the only person my team can trust to hack on this system without introducing performance regressions," switch it to, "My knowledge is valuable because I enable my team to confidently hack on this system without agonizing over performance."