If it requires changing your company compensation rules, you have different problems at hand. Great developers don't cost more in dollar signs so much as they do in operating in an environment with other great developers, working on great challenges.
You could almost argue that those who put the time and work in, are by definition the 'A' players. Even if you're not top dog in terms of technical expertise; If you've got the hunger and passion to know more you'll almost certainly succeed over time.
That's a pretty romantic way of putting it, but I agree mostly. You're dead on about so-called 'A' players who have big egos and can't communicate or play well with others; They might even be 'A' in terms of technical expertise but that's not the whole picture.
That's not what I'm suggesting at all actually. Again, you're implying this is a zero sum game, in which the world has nothing but 'A' players. Thats not what I've said.
Being a 'hard worker' is completely and totally irrelevant in software development. More input does not equal better output, which in software is the key.
You're implying that what's being discussed is a zero sum problem. We're simply saying that 'A' players work best with 'A' players, and if you fight for that in your organization then you'll do great things. 'B' and 'C' players will still exist, absolutely, but you'd do well to avoid them when possible.
Pay is actually quite low on the list of things that a great developer will value when choosing where to work. And I think it's dangerous to just lock the A players in a room amongst themselves; they need to communicate closely with others in the organization, otherwise the value they try and add might be missing the target.
Agree. Financial compensation is actually often much lower on the list of things software developers value at a company, particularly when they are 'A' players. Solving problems, working with other 'A' players, and stretching ones abilities become more important. You do have to pay competitively though.
Good stuff, dabent. I agree; Abstractions are valuable tools, but it's important to know whats underneath the abstraction, for when the abstraction leaks, or when it's the wrong tool for the job.