You need to make a clear distinction between someone offering criticism, vs. just being a Jerk. Criticism is a fact of life and when done in a professional manner it is not a sign of a bad apple. Regardless of what “authority” the rebuker speaks from, *How* they deal with others is more important than what they claim to know.

I boil this down to constructive criticism vs. destructive criticism. A constructive example is pointing out a potential flaw and discussing & pairing better alternatives. Destructive critics are the people that act like a Jerk. They point out other people’s mistakes but offer no assistance to help improve the whole of the team or the problem at hand aside from “you should go read up on {insert design pattern}.” coupled with a crude remark or condiscending look on their face.

Given I manage a team of 6 developers of reasonable skill with one highly skilled “lead”; If that lead acts like an elitist jerk harming the morale of the team, I’ll much sooner get rid of that lead than wait for the rest of the team to quit. Even if that lead has considerably more experience and knowledge than any other member. If they’re not capable of being constructive and sharing that knowledge and getting the whole product (not just “their” sections) built to the best reasonable quality, they aren’t worth it. Just say “no” to Holy Cows.

I think the distinction should be made between role and behavior. Of course a rebuke is often desireable. Does the rebuker need to start the discussion with, “Hey, asshole…”?

No, then he’s being a bully.

I would suggest the acceptance of bad behavior in high performers has ultimately led to the acceptance of bad behavior in the industry as a whole.

This allows people to write off, “Those technical guys” as “just that way.”

It’s that point where you think you should look for new work, but this job is pretty lucrative, and if you distance yourself from caring, it’s kind of funny too.

So the secret is to be a Cheerful Pessimist. Then you can’t be quantified as a bad apple and in the long run, we’re all dead anyway.

See, between Brooks’ observation that the best software developers are 10x better than the worst ones, and Wall’s observation that good software developers manifest Laziness, Impatience and Hubris as virtues, I would be more surprised by a technical team without “bad apples” successfully producing high quality software than by a technical team with “bad apples” genuinely performing 30-40% worse than if the “bad apples” were removed.

Consider: If somebody like, say, Robert C. Martin rebukes somebody like, say, me for not crafting software of an appropriate caliber for a project he’s working on, he might come off as a bit of a jerk — with my lack of quality contributing to the size of the rebuke which reflects on the sender of the rebuke, Uncle Bob, rather than the appropriate recipient, me and my piss-poor skills. (Yes, I have been personally rebuked by Uncle Bob; No, my skills — while far from astonishingly fabulous — aren’t really piss-poor.) But this makes Uncle Bob the bad apple from a organizational communication team perspective, because that perspective doesn’t understand that the output of our work is *not* fungible. So, at this point, 10 things:

01) If the team is astonishingly balanced to the point of fungibility so that nobody can rightly be bored with a project and snapping at their lessers, there’s probably not a lot of internal coaching/mentoring/growing going on. You don’t have to look at the statistical liklihood of getting good-vs-poor developers to realize that a reduced-growth situation is more likely to hold less ambitious and thus less committed developers. There’s a chance that it’s a team of bored superstars, but it’s more likely that they got a MS McCertification and are just there to collect a paycheck.

10) If you get rid of a bad apple as determined by that short list above, you’re more likely to be getting rid of the good programmers, the people who have the experience to say “this is a solved problem, let’s just reuse that solution” and the people with the guts to say “No, really, why am I here if you’re not ready to make this decision?” It’s going to be the good apples that would rather not make waves than force issues, that “tackle challenges” rather than “solve problems,” et al, that stay behind to do the work in the way that seems obvious to them. The claim that a team lacking in highly-qualified and capable people can generally perform better without them is ridiculously obtuse to the same degree as claiming that Subprime mortgages are generally good investment opportunities.

This isn’t to say that good programmers shouldn’t try to be nice, helpful and hopeful. It is to say that the “bad apple” wisdom can be very quickly conflated into shooting the messenger for bringing bad news about the project team. And frankly, it’s bad enough that the poor project got saddled by rat-hole-digging time-wasting morons who are underperforming in their job role and soiling everybody else on the project by association without a bunch of dead messengers on it, too.