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.
I agree that it operates on that assumption, and that the full-stack developer assumption is a good one. Have a read of this blog post for the mindset:
I suspect you're right, though I'd rather they share the non trade secret advice that they have in a more public fashion, such as a blog or stackoverflow.
Would you agree that being a great communicator, and growing as a person to be less nervous are aspects in the makeup of a great developer? (I'm not saying they are, just curious what you think).
I agree with you wholeheartedly, and I think the points are complimentary. I also wrote a post prior to this one, in which I argue that a team of good developers that can work together is far better than a team with one technically superior developer who can't work with others. If you can find the developer who is both technically great, and can communicate effectively in a team, you've found a very special person indeed.