> Being in Dave’s bad books meant being denied support. Support for the libraries he wrote. The libraries which powered every clients’ project.

> I was in awe of the respect that Dave commanded.

Now, obviously it's not nice to comment on one's sexual (or fashion) preferences, but sounds like this exact same thing could have happened if Dave was smoking at desk or piling used coffee mugs.

A library that powers the whole company being managed by a single guy who has to answer all others' questions, and selectively denying answers when he feels like, is not a sign of a great programmer. It may not be a sign of a bad programmer (maybe he's just tired of shit), but it's certainly a sign of a poorly run place.

I'm not an asshole, though, and it really doesn't sound like Dave was that mean, other than just having skills and strong boundaries.

And that's part of why he got away with things.

Also according to the story he did spread his knowledge rather than jealously guarding it

Dave should not have been of such importance to the company in the first place. When you hire a person who brings in domain knowledge but doesn't spread it around, you're more renting value from them than you are buying it. In scenarios when such a singular repository of vital domain knowledge is unavoidable, relationships between that person and the rest of the company must be overseen to ensure minimal adversity and maximal alliance.

At the end of the day, when you build a company you are building a team. The more each member is motivated towards the team's collective goal, the more you will be able to leverage the skills you hired onto the team towards the ends you hired them for. People like to think about technical skills as if they somehow exist independent of the human they are inside of. The reality is that the human is the portal through which the skill is delivered, and their human traits are of first class importance when considering how well they will be able to apply their skills should you choose them for your team.