Interesting article. Definitely something to keep in mind when hiring. It's crazy how much damage one person can do to a team (and vice-versa, I've seen one person change entire team dynamics).
It's also really important to be careful with jerks who think they are brilliant, even if they are. There's always someone smarter out there and clever solutions aren't always the best solutions if no one can understand them.
Alternatively, we could stop forcing the jerks to work in tightly cooperative teams. Their skills might have been useful if they would be allowed to work mostly alone.
In my experience this type of person can only exist in your organization if their manager is below average. I have come across my share of them and every time if their manager was a dud the whole company suffered, if their manager was on the ball they would put structure around the jerk to achieve a net improvement in productivity without the negativity.
This has been my experience as well, if the manager does not stay on top of it the person is toxic. With sufficient incentives, they can be managed to lift up the team.
It's always possible the brilliant jerk is just being taken advantage of so his boss can take it easy. Exploiting ego isn't hard and you don't need to be better than him at his own game to do it. If his manager is insulated from the rest of you, it's probably not worth enduring the brilliant jerk though.
spot on, I have seen people like this who you wouldn't even call brilliant but excellent Prototype-Masters. usually they flourish because they can provide cover for some deep seated insecurity of their bosses (like knowing you are technically incompetent). the problem is that such people are credit suckers because their quick & dirty prototype can pass for the real thing in the eye of 'innocent bystanders'. Overall it just lowers morale of the team as nothing seems worthwhile anymore.
Steve Jobs, Bill Gates, Larry Elison and Jeff Bezos each nurtured that sort of person (and were themselves that sort of person). They utterly steamrolled the kinder and gentler companies in their respective markets.
Sometimes reality and what you want to be true are not the same.
Yes and no. There is brilliance and there is "being a jerk" and you can be brilliant and not a jerk and the organization will thrive, or you can be brilliant and a jerk and the organization will be better off without you.
When brilliant people are managed by strong managers, those that manage to team performance rather than those that manage to individual performance, they add value by not only doing a lot of work but helping everyone else do their best work. The problem occurs when a manager is weak and the brilliant person has 'jerk' tendencies which come out unchecked. Then everyone suffers.
It is sort of like managing sociopaths, you can do it if you can set up the scoring for them such that they 'win' if the group wins. And of course that is easy to write but very hard to put into practice.
I read articles like this somethings and think "holy shit I hope I'm not a jerk" - but then I relax when I realize I'm not brilliant enough for that to matter.
It just sounds like that person was not a good match for the company culture. Many shops will appreciate that kind of drive and attention to detail, as well as the ability to tolerate potentially biting criticism that comes with it. I would have happily hired him away from the author's company.
> ability to tolerate potentially biting criticism that comes with it
I wonder if this is the issue really. Some people can't take criticism unless wrapped in sugar. If it's really, and especially if it comes with potential alternatives it should be socially fine, but it's not.
Another aspect is how the rest of the team felt over time. They probably built up deep resentment towards this person which ultimately only fed back into the cycle. So whether or not they were aware of it, they probably formed a clique to team up against this person, again only exacerbating the core issue.
Nothing in that story suggest ability to tolerate potentially biting criticism from other people. The story suggest ability to dish it out.
The dude presented opinions and preferences as facts. Is there any reason to think he would easily accept when one of juniors called him on it? Because if he would be able to accept the criticism, one of colleges would be able to convince him that some of his criticism is wrong. To me it sounds more like he used the biting criticism to keep the "top dog" position.
People who can tolerate potentially biting criticism wont present preferences as facts all that much, because there would learn from people criticizing them for that in the past.
Honestly, I was always happy to have good developers. The better you are, the bigger pain in the but you can be, as far as I am concerned as long as the code you are delivering is excellent. I am perfectly happy to work around your quirks, within reason of course.
And, of course you will be a jerk when you are seeing things others just can't and they can't understand you. After a while you lose patience.
What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
So two essential qualities in my view are: being really good, have excellent foundations and being open to learning and coaching if you don't have those.
I think it is important to match coworkers by their caliber. You're right, if you have one really amazing developer and a bunch of mediocre developers that one really good developer could become bitter.
Seems like the case here, if someone is leaving hundreds of opinion-based criticisms of someone else's work that's a pretty clear indication of dissatisfaction.
That's where mentorship comes into play - mentoring the rest of the team has greater effects than trying to plow through code over the long haul. The reason is that it creates a silo that the one high producer gets saddled with, and it creates a bottleneck that ultimately probably will even result in the high producer becoming unhappy due to being distracted with all of the maintenance burden from his/her code.
I used to be more of the former type who would try to power through everything & still display flashes of it whenever I do have to code, but after being a lead engineer for almost a year, I understand more deeply the value of knowledge transfer and making everyone more productive. Having a team that is genuinely happy to work together has an effect of creating more for the company than the sum of their parts because the team is more honest with each other from being comfortable/not having to fear reprisal, which results in better (& planned) team architecture, mistakes being caught as early as possible, and overall decreased stress.
> What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
All good developers were less-good junior developers once. What I value most is the good, patient developer that turns all the developers around him into good developers over time. They're far more valuable than someone with a high production rate but who drives others away.
That all sound good but in practice rarely is the case. Good developers and every kind of smart people, scientists, are eccentrics, because they just know more then you and it is hard to explain everything every time.
> Good developers and every kind of smart people, scientists, are eccentrics
Not always, and "eccentric" doesn't mean "unable to be helpful or kind".
> because they just know more then you and it is hard to explain everything every time
Yes, it's hard. It's a different skill than programming or general intelligence. And it's a harder skill to find or to train. As a rarer skill, it's thus more valuable, and more useful to select for. And as an engineer, developing a rarer skill makes you more valuable, which will improve your career prospects (in both pay and position).
Source: I've been on both sides of numerous performance review processes, and seen what people value at many levels of a technical job ladder.
Why does everyone insist on comparing the jerk to junior developers? Why does everyone insist that, in order to avoid jerks, you can't hire talent? There are plenty of good, talented people who are not jerks.
>And, of course you will be a jerk when you are seeing things others just can't and they can't understand you. After a while you lose patience.
What if they don't see those things because they're not being communicated well?
>What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
But it isn't necessary that those 3-4 polite junior devs are your opportunity cost. The good developer may well be alienating n good developers, testers, DBAs, Ops analysts, or BAs.
> A “No Jerks” Policy Must Be Built Into Your Culture. It is entirely possible to be extremely passionate (and even brilliant) without being a jerk. A “no jerks” policy must be preached and practiced from the highest levels.
Following simplistic rules like this is usually what leaves us knee deep in the proverbial.
Maybe I've been lucky, but I've never worked with anyone who's as much of a jerk as described in the article. In my experience, talented developers are usually intelligent enough that they can make up for their shortcoming in the social area by consciously adapting their behaviour. They're not "normal" but they function well enough to work with others.
I've worked with plenty of jerk-ish, abrasive, opiniated, "take no prisoners" people who can be very fiery in meetings and can be highly critical of other people's work. Yes, they can be a giant pain in the arse - they're just so damn challenging. But in my experience they're normally challenging because they want the company to do better.
But I've seen many times (mainly in large companies) teams that were populated and led by people who were very consensus-based, had superb social skills, and had a genuine drive to succeed - but didn't because there was not enough fire in the team to make the right choices.
To me, the business of software development is way too complex to apply a simple "no jerks" policy. Brilliant jerks are often to be found at the beating heart of successful software.
I had a frustrating moment the other day where a colleague said that
float(5)
was more explicit and personally preferred in Python than a literal
5.0
I realised I was being pedantic but I genuinely believed in "good craftsmanship" when I really pushed him to change it.
I need to get better at this because the social friction I caused may cost more than the poor craftsmanship. But the other part of me is thinking, "c'mon man... Seriously?"
It used to, but it doesn't anymore, presuming you use a reasonably recent compiler. If you enable optimizations the assembly for that snippet and the default constructor are identical, I last checked on some GCC 5 flavor, but I think it was like this all the way back in GCC 3 something.
Compilers can do some pretty fancy things with literals because they know they optimize constants known at compile time.
I just started using GCC 5.4 - I'll have to check again. Last I checked was around 4.8, and it was still generating sub optimal code with the empty literal.
I've found the first few chapters of _Crucial Conversations_ extremely useful.
Manager-Tools.com speaks very well to relationships being very valuable, worth more than float(5) vs 5.0... though... I really do agree. Float(5)? Really? And 5 should be replaced with IntNoReallyItJustAnInt(5)?? ;)
We all have that part. The trick is not to let it make you an asshole. There might be times when that's the right thing to be - satisfying a pedantic quibble over a style preference, to the detriment of morale and team cohesion, is never, ever one of them.
I have found that it's best to leave coding discussions like that to tools - we use Rubocop and Overcommit and it's a huge PITA every time it points out a minor quibble (we stop commits locally on our machines if new code doesn't pass both) BUT it saves us from having those conversations during code reviews. My general rule of thumb is that if there is a question of style that isn't caught by Rubocop, then it's very likely not worth having.
The other upside is that code reviews are higher quality and design focused.
Isnt this a very python thing. Arent all the "brillant jerks" python and ruby programmers. Java and C/C++ guys are the actually smart dudes that know what they are doing and PHP guys just want to get it working and dont give a fuck.
I can't imagine any smart developers using Ruby anyone, I know because I unfortunately work with Rails and anyone with a brain cell has already left. To me deciding to use Rails isn't a very smart decision
This one's tricky, because you're absolutely right, and telling them that won't help them improve. Try asking them, "hey I must have not read that PEP, can you link me to where that's recommended so I can get in sync?", or "hey I read this guide recently and it recommends doing X because <actual legitimate reasons>", or (best), "I don't understand why this is recommended, where can I learn more" (which hopefully doesn't end up on a holistic learn-the-world journey that ends with a 1-to-1 with your boss where you share your concerns about this developer's performance).
"Good craftsmanship" is both subjective AND hard to relate to an increase business value. Better to stick with third-party recommendations, like textbooks or linters.
Why appeal to authority here? Experienced, well-intentioned developers should able to have a discussion of the merits of a particular construct without having to turn the discussion into a citation count contest.
Ohhh boy. The problem is when the guy on the float(5) side genuinely believes that this is better code style. At the end of the day you do have to appeal to some system, whether it be to the PEP, or to SOLID design principles, or even to "someone else thinks this is a good idea on stack overflow".
Personally I like to go with "is accepted by the community" as opposed to "is accepted by most people in this room" or "Greg thinks it's beautiful".
It's not appeal to authority, it's consider the point of view of a disinterested third-party that they may not be aware of and thus can gracefully accept your feedback without losing face.
Unless you can prove that one method is significantly faster or the other structurally dangerous, it is just a matter of coding style and opinion. Agree to disagree, or let the lint tool be the referee.
I did the lazy approach and let timeit pick the count. Specifying the number of loops doesn't change the result:
$ python -m timeit -n 10000000 'float(5)'
10000000 loops, best of 3: 0.0771 usec per loop
$ python -m timeit -n 10000000 '5.0'
10000000 loops, best of 3: 0.00717 usec per loop
[timeit] provides a simple way to time small bits of Python code. It has both a Command-Line Interface as well as a callable one. It avoids a number of common traps for measuring execution times. See also Tim Peters’ introduction to the “Algorithms” chapter in the Python Cookbook, published by O’Reilly.
Yes. The difference is the Python compiler is not optimizing out the float() conversion, so every time it creates the value 5.0 it is calling the float() conversion on the literal "5".
Different machine, so the timings are different from above, but here are some permutations:
Float literal:
$ python -m timeit '5.0'
100000000 loops, best of 3: 0.0152 usec per loop
Integer literal coerced to a float:
$ python -m timeit 'float(5)'
10000000 loops, best of 3: 0.146 usec per loop
Float literal coerced to a float:
$ python -m timeit 'float(5.0)'
10000000 loops, best of 3: 0.143 usec per loop
Integer literal:
$ python -m timeit '5'
100000000 loops, best of 3: 0.0152 usec per loop
Float literal coerced to an integer:
$ python -m timeit 'int(5.0)'
10000000 loops, best of 3: 0.155 usec per loop
Integer literal coerced to an integer:
$ python -m timeit 'int(5)'
10000000 loops, best of 3: 0.14 usec per loop
Very cool thanks. So something like PyPy would probably very quickly optimize it, since it has a deterministic result. I think I'm going to experiment with that one.
Jerks and non-jerks have different approaches to building enterprises. Jerks often rule through intimidation and fear. Non-jerks build loyalty through other mechanisms.
The thing is both methods, if applied consistently, produce results. The trouble is the jerk method is a lot less efficient in terms of use of human emotional capital.
I'm really not convinced that Linux is successful because of Linus's jerk-ness.
I think it's successful because the BSDs were under a cloud of legal suspicion in the early '90s (the USL lawsuits) and Mach didn't have zero-copy message passing, and so as a result, Linux was basically the only free software general-purpose UNIX-alike for 386s that existed. (MINIX resisted being general-purpose until 2005.)
Once you have that, it's basically a matter of network effects.
There are a ton of things Linus did right, of course. There are also a ton of ways he could have destroyed the project, but didn't. All of those are praiseworthy. But we have exactly one data point, and I don't think we can extrapolate a rule from that, certainly not a rule that everything he did was right. If there had been Linux and 386BSD competing on equal terms, who knows what would have happened.
Brilliant jerks are, in fact, often to be found at the beating heart of successful software. That is true. But would that software have a different beating heart if not for them? Would it be more successful?
He may flame on mailing lists from time to time, but I prefer an honest character to CoC thumping Machiavellis who talk and behave like politburo members.
The latter actually harm and exclude people while acting politely; Linus does not.
I have near unlimited respect for Linus. He has an allergy to bullshit. He does not mince words when preventing any kind bad code or needless complexity from entering the kernel.
The same things that make some people consider him an "asshole" are the same things that make him so effective.
I agree... usually when a truly brilliant developer is causing more harm than good, it's because they aren't being effectively managed. That doesn't mean managing them is easy, but you want to pick and choose what problems you give them, who they work with, and how they work with customers. Of course, that's not my job :^)
Usually? The overlap in the Venn diagram between "Truly brilliant developer" and "giant baby who has no social skills" is probably non zero, but I work with many brilliant non-jerks. Perhaps you've been unlucky.
As opposed to intelligence and sociability, among other traits, may be independently varying?
If one imagines that intelligence and sociability are merely two of many possible desirable traits, and that top firms with big budgets also see similarly, then eventually those with the highest concentration of desirable traits will be sniped up, leaving firms with lesser budgets to take those with fewer desirable traits of lesser magnitude.
The same can be said about customers. Some customers could be described as "10x paying nice customers", vs "10x paying jerk customers", and these could be thought of as merely two of many possible independently varying traits. Eventually, one might suspect that discerning firms will try to keep the best clients, while pushing clients with fewer desirable traits of lesser magnitudes to lesser firms.
And the big win is that it's quite possible to go from "asshole" to "amicable." It's less likely someone goes from "mediocre" to "brilliant." A good manager can go a long way in coaching you professionally, but they can't raise your IQ.
> In my experience, talented developers are usually intelligent enough that they can make up for their shortcoming in the social area by consciously adapting their behaviour.
That's orthogonal to the issue mentioned in the article. For the purposes of "not being a jerk", it doesn't matter if that comes naturally or if you have to devote conscious effort to it; only the resulting behavior matters.
> Brilliant jerks are often to be found at the beating heart of successful software.
Survivorship bias. Strange policies or properties are often found in successful companies/projects, who often write up articles about them as though those policies contributed to their success, never considering the possibility that they succeeded in spite of them. The same goes for jerks: some companies/projects succeed in spite of the jerks in (or running) them.
OTOH, you can make a pretty strong argument that for, say, MS, Oracle, or Apple, it's precisely the 'jerk-y' qualities of their founders and CEOs that led to their success today.
Say what you like about MS's business practices during the 90s, but I think the history shows that a large reason they were able to continue their dominance was because of the unfair and frankly anticompetitive practices that they embraced back then. Bill Gate's willingness to be a jerk was what kept their company on top.
Of course, that was directed productively and outward, not destructively inward.
fwiw that kind of phrase isn't necessarily 'jerky.' As long as the person you are saying it to understands that you respect him/her, and are just disagreeing with their idea, then it can be fine.
It's a risky communication strategy, but I wouldn't condemn everyone who uses it.
> As long as the person you are saying it to understands that you respect him/her
what kind of person would say that with full vitriolic sincerity to someone they respect? Why say that when you could say, "I strongly disagree for the following reasons..." or something else similarly diplomatic and actually productive?
Oh right, and I forgot Marc Andreesen. This was from The Hard Thing About Hard Things:
To: Marc Andreessen
Cc: Mike Homer
From: Ben Horowitz
Subject : Launch
I guess we’re not going to wait until the 5th to launch the strategy.
— Ben
To: Ben Horowitz
Cc: Mike Homer, Jim Barksdale (CEO), Jim Clark (Chairman)
From: Marc Andreessen
Subject: Re: Launch
Apparently you do not understand how serious the situation is.We are getting killed killed killed out there. Our current product is radically worse than the competition. We’ve had nothing to say for months. As a result, we’ve lost over $3B in market capitalization. We are now in danger of losing the entire company and it’s all server product management’s fault.
Most people can see through "I strongly disagree for the following reasons..." as a euphemism for "your idea is stupid, and this is why..." And the more you emphasize "strongly" in the former, the more likely "fucking" materializes between "is" and "stupid" in the latter.
That kind of bland vocabulary makes one's statements sound like limp static. Corporate dialect is contrived to remove strong (corporate-environment-inappropriate) emotion from your speech. If you're well acquainted with your colleagues, then I'd hope you could express yourself more genuinely. You're probably more relatable than a peppy talking head who never offends anyone.
In this cases, shouldn't the discussion be purely about the technical merits of the idea, rather than emotions of the people speaking about it? I would count removing unneeded emotions from the conversation as a positive thing.
I'm a machine learning engineer so "unneeded input" is something I rarely consider as a valid statement. Oftentimes when you're arguing the merits of one approach versus a different one, you have to use your rhetorical skills to influence another party. You both believe you have the best solution. You believe your logic is consistent and complete.
Emotion is a very powerful signal during discussion. It's a counterpoint to logic; they work together. Rarely does logic by itself win anyone over. Trying to remove "unneeded" (who decides what an unneeded emotion is) emotion is folly. We're not Vulcans.
So, all things being equal and arguments having the same merit, the less polite and less rational person wins. If i am able to contain emotions and argue by facts only, I will be at disadvantage.
Diplomacy is not always necessary to get productivity.
Tip-toeing around the issue can make things much worse.
It is much easier to say, "Stop. That's stupid, try again."
Than to try and cherrypick what they've done right, because often times, there isn't anything useful there.
Considering that Gates, Jobs, and Torvalds all have stories where they tell someone what they're doing is stupid, and actually get a decent product out at the end of the day, it doesn't seem like diplomacy is necessary at all.
If you can't say ~why~ it's "stupid," your comment is not useful. And if you do say why it's stupid, those reasons are much more important than the inflammatory adjective "stupid," so just say those instead.
It's hard to feel respected when you're constantly hearing all about how "fucking stupid" your ideas are. I know in theory you're supposed to separate criticism of your ideas from criticism of you, but in reality that isn't always easy when the statements being made are so strong.
Yeah, it's a risky strategy. I recently interviewed with a company that had "thick skin" as one of their hiring criteria, and told candidates that they insulted each other, and someone getting hired couldn't take things to seriously.
Context is everything. Profanity and hyperbole are as far from the aloof and stuffy professional language one uses with unfamiliar people or those in higher positions. It's something that becomes appropriate in personally close and comfortable quarters, and it can be a signal of comradery.
> I think the history shows that a large reason they were able to continue their dominance was because of the unfair and frankly anticompetitive practices that they embraced back then
While there might be a correlation, I don't think you can entirely extrapolate between "ruthless business practices" and "toxic interpersonal interactions". You can have either without the other, and I wouldn't automatically assume that skill at one implies skill at the other.
I'm willing to bet that there is a correlation, to some extent, of level of jerkiness one can tolerate and income. The more jerk you can tolerate, in many types of companies, the higher you can move up. (to a certain extent, above a certain threshold; and the correlation is probably stronger among larger companies.) Mostly due to shifting upwards and towards the business side of things; management, strategy/biz development, or what have you.
For example, the person who wrote this article, is less of a fit for a cutthroat, decisive, business-minded management position; and might maximize their relative potential (in their current situation and state) by reaching a level that's below any business-minded interactions.(captain of a development team, answers to a manager who isolates them from business/mean/jerkish discussions.)
In more ways than one. When jerks are allowed to be jerks, people who do not want to deal with jerks leave the company. So the jerks bubble up to the top, while otherwise great engineers who don't want to be berated move along to better things.
Exactly. You have to pick: either the jerks, or the people who the jerks drive away. And that doesn't take into account the people who aren't quite driven away but find work that much more unpleasant as a result.
If you encounter many skilled jerks, consider why that might be, and why in the same environment you don't also encounter skilled people who are fun to work with. In such an environment, the skilled people who are fun to work with can afford to leave, while some of the non-skilled people may not have that option. So, it's natural that within such an environment (company, project, etc), it'll look like a correlation between jerkiness and skill. People then start assuming a causation, and thus contribute to that same cycle.
The opposite environment, with many skilled people who are fun to work with, will tend to reject jerks regardless of skill. I've also noticed that such an environment tends to have a much higher degree of mentorship and collaboration, in addition to being more fun to work in, and boosting energy rather than draining it.
Entirely possible. But the viewer may also just be in an environment with skilled jerks that have driven off skilled non-jerks. So whether the viewer is a jerk, nice, or indifferent won't necessarily change the apparent correlation they observe around them between jerkiness and skill. The danger lies in generalizing that observation and assuming it applies outside that environment.
Having worked at a company with very nice people and no fire to actually get things done (just platitudes), it can be just as bad of an environment if your goal is to succeed. Often times people come in to "play work" and achieve only a fraction of what's possible.
Fire and courtesy are hardly incompatible. But it's more than twice as hard to achieve both as to manage one or the other.
It's also a question of circumstance. Right now, for example, I'm working to mitigate, and eventually to resolve, a morale crisis on my team, which exists for good and cogent reasons that don't merit discussion here. Now is not the time for fire - and fire alone in any case works only when the vision is so powerful that smart, capable people will tolerate being driven painfully hard to achieve it. Without offering something to make that worthwhile, fire can't drive them onward - it can only drive them away.
Fire is not always the solution to any problem of course, but a lack of being results driven can make for large morale problems in itself - especially in engineering where you can keep working on one insignificant detail or another in perpetuity. I've spent months constantly asking for business goals to be set so we can meet them and being told to hang tight. I've left those companies because the environment becomes quite toxic over time, with the "true believers" believing that everything is going swimmingly because they don't have any pressure put on them, and the ones looking to accomplish things spinning their wheels fiercely in the mud.
In any case, I'm not trying to argue with you, and I hope I don't come across as if I were. It's just that I feel like there's a strong reaction in this thread to a bias, whether perceived or actual, on the part of the article author and in the direction of courtesy. So my purpose here is to sound a cautionary note, and attempt to keep visible in the discussion what I regard to be the nuance of the matter.
Especially since a lot of engineers default to brusqueness, which I totally understand while finding often counterproductive. It can work in a collegial setting, among secure peers who share mutual respect, but in any other context it just looks like asshole behavior - and that is exactly what it is.
To understand one's audience, and adjust one's persuasive style to suit, is a fundamental aspect of rhetoric, and given the ubiquity of office politics and the necessity thereof - a topic meriting its own essay, which I will not write on a phone - such understanding and adjustment is important to professional success, as well. I think that's something it is easy for us to overlook, because computers only need to be told and then sworn at, not persuaded.
Also, all else equal, it's both more ethically sound and more useful not to act like an asshole. Leaving a trail of hurt feelings behind you is no way to go through life. Sure, we might excuse it in someone with a vision on par with that of Steve Jobs. But no one here is on par with Steve Jobs.
> Brilliant jerks are often to be found at the beating heart of successful software.
Survivorship bias doesn't render this an ineffective argument against the simple "no jerks" policy argued for in the article.
The contention is "(jerk present) → ¬ (success)", aka "¬ (jerk present) ∨ ¬ (success)". A single case of "(jerk present) ∧ (success)" is sufficient to disprove the direct implication.
> The contention is "(jerk present) → ¬ (success)"
The contention in the article is not "you can't ever succeed if you have a jerk on the team" or "a jerk will always cause your team to fail". A property doesn't have to be universal to be common enough to be worth writing about.
So no, a single instance of succeeding despite a jerk does not "disprove" anything relevant here.
> To me, the business of software development is way too complex to apply a simple "no jerks" policy. Brilliant jerks are often to be found at the beating heart of successful software.
That's what you replied to with "but survivorship bias!". And the article itself says:
> A “no jerks” policy must be preached and practiced from the highest levels.
... which is a universal and normative call to action.
English isn't formal logic, and treating it as such creates a strawman. An article recommending a "no jerks" policy is not a formal theorem that "jerks universally lead to failure", nor can it be refuted and dismissed by an anecdote of "but we had jerks and didn't fail".
If jerks universally led to failure, it would hardly need writing about more than once, as everyone would very quickly have to understand and deal with it. However, because you can sometime succeed in spite of the presence of jerks, that makes it a problem particularly worth writing about.
Please don't. Our industry is already full enough of assholes who saw part of the Steve Jobs movie and started to think that management is all about berating or "negging" people so they do what you want.
I stopped reading when the blogger started talking about the "brilliant developer who could code circles around us", and then referred to him as a "10x developer".
These are stereotypes, and quite often bloggers will make up stories to illustrate a point. Which is fine, but when your point is based upon stereotypes, then I'm not interested.
----
So with that said, I agree with everything you've said. Quite often these abrasive people are making valid points.
You know those security scandals that hit (Playstation network getting hacked, etc) where you think to yourself "how the fuck did they manage it so badly, because their fuckup wasn't subtle at all.
You KNOW there was an abrasive jerk somewhere in there saying "guys... this is horrible" and he or she got shouted down, shutdown, and/or fired for it.
That, or they had a reputation for "moving fast and breaking things" without submitting to any secure practices, and the abrasive jerk who knows security never bothered to apply there in the first place. Or the polite person who knows security, for that matter.
Or there was an abrasive jerk who made them to do the wrong thing. Abrasive jerk was likely to be the one doing then shouting down. Abrasiveness does not make you right, the assumption that the most pushy jerk is right is just wrong.
We should be putting "abrasive jerk" in quotes. The point that was being made by both of us is that these abrasive jerks aren't actually abrasive jerks, they're just going against the grain because it's the technically better choice.
And then they get labelled as abrasive jerks and ignored, and then queue the scandal when people talk about how horrible the toyota code is (for example).
How do you know the jerk is jerking for the technically better choice? You don't. These debate always assume that the person who is doing criticism is right. That is not the case in real life. Criticism can be both right and wrong.
Note that these people did not really bought into his theories and opinions nor were able to follow his instructions - the amount of code review complains would go down it that would be the case. He did not managed to change the culture toward good nor to teach them. His reach was limited by what he was able to micromanage at the moment.
No, you're right, I'm sure that somehow Sony managed to hire an entire team of sys admins that were so incompetent that none of them actually realized just how vulnerable their system was.
like... every. single. one. of their sys admin team was really that oblivious. Out of all the people they hired, not even one competent got accidentally picked up somewhere along the way, during all the years they were were running that network before it happened.
Or maybe, their sys admin team was acutely aware, but management didn't give them the autonomy to choose to fix it, and anyone who spoke up and tried to push for the issues to be fixed got labelled as "not being a team player", or a "troublemaker", or even ... gasp ... an "abrasive jerk".
And then they got booted, and everyone else learned the lesson and just shut up and kept collecting the paycheck.
And then suddenly they get hacked, and then finally management was willing to spend the money on securing things better.
1.) It is perfectly possible to have bad hiring process. That might not be just management fault, technical skills needs to be checked by the technical team. Abrasive jerks in it will select for conformity with their opinions instead of knowledge.
2.) It is perfectly possible that abrasive jerks were the ones who prevented others to fix the problems. In particular, they could have created a culture where new employee or junior is not expected to accept all criticism but is shut down when he dish it out.
"This is stupid" is not exactly an argument - if that works then your tech seniors are preferring conformity with jerk over merit of argument. It works somewhat when all working with him are juniors (e.g. less likely to see bigger problems), but makes you impenetrable to valid criticism from other skilled people.
3.) You assume that the problem was lack of autonomy from the management. That is possible, but it is equally possible that tech team screwed up on their own. Organizing larger teams is hard and even super skilled techies, abrasive or not, may completely fail once the group is too big to be micromanaged.
---------------------------------------------
Being abrasive and being direct/open is just not the same. Abrasiveness makes people comply, because they do not want to be humiliated by you. Abrasive people are just expecting everyone to be conforming to whatever they think, they do not create an environment where bad processes get fixed. It does not make people agree with you and they will revert back to the original behavior the moment you don't see.
I think abrasive people tend to be very contrarian. And when large companies like Sony make terribly boneheaded decisions it's not because every individual simultaneously made the same stupid decision. It's because everyone was drinking the cool-aid. And abrasive people are generally far less likely to drink the cool-aid. So I think when a a large company makes a boneheaded decision the people arguing against that decision are more likely to be more abrasive than general populace.
I'd rather have a brilliant jerk than a regular jerk.
But regular jerks abound at work because they at least don't make you feel stupid and insulted.
And you hit the nail on the head with your experiences. In high school I was neck-and-neck academically with a brilliant jerk. He went to Harvard, is now a millionaire (without inheriting it) and a much nicer person. Competing with him was one of the most formative periods of my life. He made me better, because I learned not to take harsh criticism and hectoring so seriously. Look at what they do (for you), not what they say (to you).
I actually wish there were a brilliant jerk like him in my workplace. But there are just regular jerks.
Maybe I'm the exception, but I have worked with someone as bad as the article described. He would re-write everyones code when they weren't around, because he didn't consider it good enough, so they were completely de-moralized. Eventually he was assigned solo projects, which became overly complex and were never finished, until he left the company. Management should have noticed earlier how unproductive he was to have around.
That doesn't sound so much like a brilliant jerk as a midwit egomaniac, which are pretty common on the ground in programming. I've worked with people like that too, and what they're really doing under the guise of making your code better is rewriting modules because it's less trouble than figuring out how the existing code works. Invariably they break something in the rewrite, too, because they didn't understand the full scope of the problem domain (which, circling back, is why they didn't understand the original code).
And of course when you assign them to solo projects they fail. Because they're not very good at software development.
That's very well put. The "mid-wit egomaniac" is much more destructive than the "brilliant jerk." The jerk at least knows that rewriting working code is expensive and risky.
That's probably pretty accurate. He was really brilliant, and had extremely broad technical knowledge, but he was not as brilliant has he believed himself to be. Since his code was difficult for anyone else to follow, and as mentioned earlier, everything was over-engineered out of existence.
Success can be determined by many different things; but pretty universally in programming not getting the job done correctly (the expected inputs and outputs just aren't there) is an issue.
Which confirms your interpretation and labeling of the 'midwit egomaniac'.
The sad part - it is not usually immediately clear which kind of jerk your dealing with, since they behave the same!
Secondarily, it is not immediately clear to an outsider upon observation which is which either...
Summary I drew: There are genuine mental health related conditions that can cause someone to be a jerk AND still be brilliant. When you find that, you have to first separate them off so as not to detract from others work. Secondly if they can't cut it then let them go.
I tell myself I can work with (almost) anyone who is trying to do better. If someone is intentionally being subversive, that's hard to work with. Humans are difficult, and the people that own that & try anyway are my kind of people.
> I've never worked with anyone who's as much of a jerk as described in the article
Maybe it's just that jerks don't affect you as much as they do other people. And that's great- for you. But for the rest of the team around you, those people are awful. Those people are the reason your best teammates decide to move on to new opportunities.
You should also consider the old saying 'every team has an idiot, and if you don't know who the idiot is, it's you', and double check that this doesn't also apply to jerks. Maybe the reason you haven't worked with a jerk before (and in fact believe brilliant jerks are just the best) is because you are the jerk.
I don't mean to say that as an insult. I was the jerk. I still am the jerk sometimes. It's hard to see, hard to deal with. Maybe you aren't, but it's worth careful examination just in case, no? Otherwise, you're literally making people around you miserable.
> Those people are the reason your best teammates decide to move on to new opportunities.
Are they? Most devs I know change jobs to work on more interesting projects, to move into a higher level role, to get a pay bump, to move to a more flexible company, etc.
In my experience it is rare for someone to move because of bad colleagues. Bad management? Sure. Bad co-workers? Not really.
Why do you work at companies with so many jerks? Perhaps you are the problem.
I think it's possible to be truthful, direct and blunt while still being nice and thoughtful. There's a false association between someone who is a jerk and someone who is willing to disagree.
Every organization needs a rogue here and there - one who will challenge conventional wisdom and authority in confrontational, i.e. jerkish, ways. It's management's job to try to fit them in and put them in the right positions. I'm sympathetic because I'm very socially inept myself.
I belive that "no jerks" policy basically means that everybody needs to be nice and civil with each other.
This does not mean that mistakes are allowed and things are done by consensus.
The problem with jerks is that they are jerks: people do not like them and it is hard to work with them and that is not good. Nothing else. Sometimes that is ok - but in many cases it is not ok since team and project needs to grow into other areas where that "brilliant jerk" will not be so brilliant.
The problem is that the meaning of "civility" is mutable. Too often, "being civil" or "being nice" or "being respectful" ends up meaning going along with the flow and not challenging the group consensus.
No they don't; mediocre 'nice guys' do though. Every 'brilliant jerk' I've worked with and led has been a net positive over the long haul. Every mediocre nice guy has been dead weight that costs everyone around them time.
I'll take the brilliant jerk any day. They can simply deliver in ways that others cannot.
> I'll take the brilliant jerk [over the mediocre nice guy] any day.
Holy false dichotomy, Batman. I'd rather take neither of them and fill my team with adequate-to-exceptional devs who also happen to be decent human beings.
If brilliant means not mediocre, or above average, they are as rare as they are common. Depends how your budget stretches; If it doesn't, you have to make do.
I didn't say there's no middle ground. Of course I'd prefer the brilliant nice guy, but you don't always have that option.
I disagree on 'adequate' though. I'll take a truly brilliant a-hole over 'adequate'. 'Adequate' means I'm often fixing their mistakes, checking up on them, making sure they stay on track, etc. I'm ok with smoothing over issues from time to time if it means I can let them run wild on the thing I hired them for.
If you believe that niceness (the opposite of a jerk?) and brilliance are independently varying traits, and that each are sought after in the market, then you might suspect that eventually those who have the greatest number of independently varying good traits will be more likely to be sniped up by discerning firms than not.
In which case, based on your budget, you'll have to settle with fewer and fewer desirable traits of lesser magnitude, or conversely, based on your budget, you can push more and more less desirable humans to lesser firms; one can imagine thinking the same with customers or clients as well.
You can have the nice paying client, or the jerk paying client, and a discerning firm might prefer nice paying clients over jerk paying clients (but of course, the most important discernment will be over pay), leading their competitors to have to deal with clients with a smaller set of desirable traits.
If your head count is 5 or less, one brillian jerk (BJ) can carry the team on his shoulders. If BJ's a 10x programmer, and the other option is to hire a brillian and nice (BN) who's merelly an 8x programmer, you are better off with the BJ as tech lead. Assume your core team was 5x, 4x and 2x before the hiring of the tech lead. The 4x and 2x guys will probably slow down BN to 6x, so you end up with 17x of team throughput. BJ, on the other hand will make 2x quit out of frustration, and 4x will be demoted to 2x because he will struggle to cope. 5x, on the other hand, is pushed beyond his zone of comfort and raises to 6x. Now you have a team throughput of 18x, but you will be paying one less (junior) salary.
That extra throughput is also better spent because instead of 4 people discussing how to do things, there's 1 jerk bossing around 2 non-jerks. Cancel all team meetings!!!
Now, make the team size 15. Most of those will be 3x and 2x programmers as well. Seeded with a 5x, two 4x and the village idiot (VI, whom we will peg at 0.5x, just for the Lulz). So, the BJ has the VI kicked out, starts making much neglected changes, and everything seems to be going in the right direction. But then, your rank and file get demoted -1x because they also cannot cope with BJ's rapid changes. BJ might be seen as keeping the boat afloat, but in reality his productivity is neglected by everybody else's fuckups (which are BJ fault, because he cannot be bothered to let the team know what he's doing). 5x and one of the 4xs quit in disgust of the general chaos, and 6 months later, they are back with a competing product and poaching the big team clients.
So, it does not sound as if BJ "delivers" as much as you thought, does it?
>So, it does not sound as if BJ "delivers" as much as you thought, does it?
I guess not, at least, within the context of your little story.
To be fair, I am thinking of small teams, and I can imagine how their value would decline in larger outfits.
That said, I don't hire people to write CRUD apps either. Truly brilliant people should be working on solving hard problems which lack a general solution, not data layers and library duct tape.
Says who? This has never been my experience. They are tolerated specifically because they deliver. If they're not delivering then why are they still around?
Same here. The so-called "jerks" are still just people and leadership is all about managing different personalities. I've yet to encounter a case where the even the most difficult person couldn't be handled properly. Any occasional issues are more than worth the productivity increases.
The bit about improved productivity seems dubious.
One of the problems in this industry is that a lot of teams have no real measure of their actual productivity. We have scrums and points and velocities, but seldom have any way to know how this actually compares to other teams, or any other benchmarks.
I've been dropped in on teams that had spent long periods (in cases years) creating trivial solutions. They were productive in their own way, generating huge volumes of code, had a great sense of satisfaction about their process and a sense of accomplishment, but what they were creating was a week of work for a single person if correctly built. And they happily enjoy their synergy until they are outsourced or eclipsed by competitors.
Maybe I'm sensitive. I've been "the jerk" before. I once had a coworker complain to HR and my boss because she felt that I was domineering. I was domineering in this case because I had opinions and expressed them to the team, and their opinion and suggestion of a new process was that we should have "opinion roundtables" where each participant gets the same amount of time to talk with a timer, etc, and need to suppress any suggestions or opinions outside of that period. I left that team and organization, and eight months later the team was fired.
Following combination would slow them down: "Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds." with "Most of the comments were opinion and personal preference. [...] He never took the opportunity to teach or mentor. He just stated his opinions as fact."
That sort of behavior generates a lot of work to the rest of the team - time spend changing the code, time spent discussion opinions and trying proactively writing the code in way that will pass his review. Time spent being confused over why this or that was wrong again (since it was not wrong actually). If those less experienced people feared him, which is likely, they spent a lot of time attempting to anticipate his opinions and preferences (while sacrificing their own opinions and preferences even when they were right).
Moreover, people like him would cause other experienced people to leave. While junior might be fine with being expected to submissively conform to someone elses preferences that much, experienced person wont. "You are doing it wrong" might work on junior, but not on someone who knows that he is not doing it wrong. Anyone who is willing or wanting to take on responsibility would leave.
Yet moreover, he likely regularly shot down good ideas of other people, which would make those other people more passive. It is the same effect as why micromanagement has.
On the subject of making code reviews a positive experience I think it has been helpful where I work to explicitly discuss code reviews. What makes a good code review vs. a bad one. For example the idea that code review comments should be based on the substance of the code rather than style.
This stuck out to me as I tend to be very critical in code reviews, which I think made other developers uncomfortable. By talking about it though I was able to soften my approach. I was also able to make sure my language came across as reviewing the code, not the developer.
to call anyone a "jerk" is something that only jerks do, but everyone looks at themselves as holier than thou. We're all flawed in some way. Labeling people (or attacking people) as "jerks" is in profound violation the principle of non-violent communication, to say the least, and, by the way, so is down-voting those who are critical of the prevailing opinion here without a civil counter argument ;-)
Here's the thing: some people are jerks. Calling a jerk a jerk is fine, IMO. (Some people are racists; calling a racist a racist is also OK.)
Avoiding calling someone exhibiting a negative behavior by the accepted label for that behavior is healthier than tiptoeing around and pretending that Hannibal Lecter just has different dietary preferences and that's OK.
My point is that we're all jerks, one way or another, just don't really know it or admit to it, but we know that everyone has done something that warrants them being called a jerk by someone. No one lives a whole life without being called a jerk by someone. I once thought Mother Theresa was a jerk for being so nice. These labels are subjective and inflammatory. and don't help the situation.
I was thinking the same thing. There are diminishing returns with most jerks if they are marginally better than the rest of the team, but if they are 10x better, maybe you just need a team of 1.
One of my favorite interview stories was when I was interviewing for a very low-level dev position at a major telecom. I was interviewing to become member #8 or so on this team.
It was for writing dial-up internet billing software, essentially grant/deny access and provide hours connected to the dial-in banks. Nothing all that crazy, a pretty solved problem honestly by that point.
I asked them what they were replacing and why. The team lead got super excited and talked about how they were hired on to replace a single guy who had wrote a ~1000 line Perl script that pretty much handled this whole data import job. This guy apparently made the cardinal sin of using moderately complex regex in his tooling, and that was a sign of how incompetent he was and how the tooling obviously needed to be replaced wholesale.
They did not get the irony of this situation whatsoever when I made the obvious statement of why it took an 8 man team over 12 months so far to replace a single dude with a 1000 line Perl script. Absolutely saw nothing wrong with the situation whatsoever.
Thankfully I ended up not taking that job and starting my own company instead :)
No matter how much two such folks might deserve one another, I'm not sure companies could afford to watch their final two coders refuse to cooperate over trivial shit like line length.
Maybe, but it's also true that cranking out code is not the same as qualify software development. Lots of people can churn out code, that's the easy part.
There's an implication later that he might have been 10x because he was cutting other people down – turn everyone else into a 0.1x developer and the 1x developer starts looking good.
I'd take that claim skeptically. But another consideration is that more than half of a team's work isn't code. You have to write the right thing, not just something, and that requires time and communication. So he might have been a 10x coder and a 0.1x communicator – indeed since he seemed to have little interest in interpersonal relations, some amount of his performance may have been due to his own time allocation choices.
Two of those people together would perform very poorly on some projects. And very well on others, depending on the clarity of the project and the amount of technical challenge it presented.
In my current job, I have to deal with once certain 10x programmer with... how to put it charitably... some distinct lack of social graces. He's better than everybody else but not 10x better, also, he does not make everyone 10x dumber, thought there's some rework that everyone has to do to accomodate his demands.
I have come to believe that about half of his enhanced productivity is simply that he's a rock star and management tolerates him (but not everyone else) cut the red tape. In general, every commit has to bee peer reviewed, but he just jumps and ninja edits the code base at leisure. Everybody is supposed to run regressions before commiting, but from time to time, things will stop working and it will be some of his transactions behind it (which is discovered after multiple people could not do any productive work for half a day, trying to figure out what when wrong with their own work instead). If some tool or another is suboptimal, he will just roll out his own and be done with it (leaving the rest of the team to learn how to work with his prefered tools, instead).
Fortunatelly, we have other very strong developers that act as counterweight to him. Unfortunatelly, they also come with their own quirks of character and you are bonded to run into one of their pet issues from time to time.
I honestly enjoy working with those "brilliant jerks", if they are actually brilliant I will learn from them. And debating with them is very entertaining.
Same, it accelerates your growth. Can you believe OP? There he has a brilliant dev taking his valuable time to critique his and other people's mediocre work, and all he gets for it is self-protective and defensive reactions from everyone else. OP has admitted that the brilliant jerk had good reasons behind all his comments, yet here he is still complaining about it (ego much?).
Sometimes yes, but there is the question of budget. If that was a project or contracting work, and the client can be sold 6 people, then it looks like bigger work, and can be charged more. If you just put one brilliant dev to do it, the client might not be convinced that the job is as big as you tell him. Sometimes devs are put on projects just to "sit it trough", they are needed for the headcount.
My first senior engineer was a "brilliant" jerk. He had decades of experience, but when I started digging into his work I realized that he was useful mainly because he was offering solutions to problems that he created. I've heard some people say that a good engineer will eliminate the need for his/her own job. This guy was actively creating a need for himself by causing problems without management realizing it.
About 1 out of every 10 ideas was a good idea, but you had to know how to filter out the bad ones. If you said "no" to one of his bad ideas, he'd say that you weren't listening to his input and complain to your manager.
He was abrasive, condescending, and dominated every meeting. If you said anything to management, their response was "Oh that's just Bob, what a crazy, quirky, eccentric guy!" What they refused to realize was that being Bob's peer was very different than working for Bob. What management perceived as a quirk, was a character flaw that made life hell for anyone working underneath Bob.
And to echo other comments, nothing was done about Bob because management didn't want to take responsibility for the culture of the company. Why risk negatively impacting profits by actually managing your employee when you could blame it on millennials being whiny and you believe that engineers are interchangeable?
While I don't doubt the author's employer did the right thing – to fire the individual – I think the subsequent logic (e.g. guard against "jerks" at all costs!) is a dangerous train of thought, one which is more likely to pigeon-hole human beings.
In reality, no person is "simply a jerk". Each of us sits somewhere on a spectrum of intolerance towards others for one reason or another. It's healthy to learn how to work with people of all stripes – even individuals who can, at times, be abrasive.
If this article were actually true, Apple wouldn't exist as the company it is today. Steve Jobs, while not a developer, was undoubtedly brilliant, and most definitely a jerk.
It's unhelpful to pigeonhole people and then extrapolate out their actions from there, because for the most part people don't conform to whatever mental model of that stereotype you've built in your head. People are complex beyond imagining.
Besides, what's the author's sample size here? One? Two? It's an anecdote worth relating, to be sure, but I think it'd be better served by leaving the "Brilliant Jerk" bit out, and leaving it as a story about team morale being more important than the contributions of any single team member.
I think the argument is that most guys like Jobs or Gates aren't jerks. They might be a little abrasive but people often want to work with them over long periods of time.
This could be turned around: Nice Mediocre People Cost More Than They Are Worth.
I've seen a lot that socially desirable behavior is evaluated and preferred rather than people doing excellent work. Group dynamics quickly exclude these by creating a consensus of what is accepted and what the goal of the group is. This is especially easy because these brilliant people are always -by definition- a minority,
Can't the same advice be given to the jerk? Grow up and stop being a jerk?
And really, if we're in the business of shipping working things on time, do you think it's a good idea to keep someone on who's going to bring down the rest of your team, or drive them away?
278 comments
[ 3.3 ms ] story [ 458 ms ] threadIt's also really important to be careful with jerks who think they are brilliant, even if they are. There's always someone smarter out there and clever solutions aren't always the best solutions if no one can understand them.
True brilliance includes the ability to recognize and govern how you are affecting others.
Thank god I dont work there anymore!
Sometimes reality and what you want to be true are not the same.
When brilliant people are managed by strong managers, those that manage to team performance rather than those that manage to individual performance, they add value by not only doing a lot of work but helping everyone else do their best work. The problem occurs when a manager is weak and the brilliant person has 'jerk' tendencies which come out unchecked. Then everyone suffers.
It is sort of like managing sociopaths, you can do it if you can set up the scoring for them such that they 'win' if the group wins. And of course that is easy to write but very hard to put into practice.
I wonder if this is the issue really. Some people can't take criticism unless wrapped in sugar. If it's really, and especially if it comes with potential alternatives it should be socially fine, but it's not.
The dude presented opinions and preferences as facts. Is there any reason to think he would easily accept when one of juniors called him on it? Because if he would be able to accept the criticism, one of colleges would be able to convince him that some of his criticism is wrong. To me it sounds more like he used the biting criticism to keep the "top dog" position.
People who can tolerate potentially biting criticism wont present preferences as facts all that much, because there would learn from people criticizing them for that in the past.
And, of course you will be a jerk when you are seeing things others just can't and they can't understand you. After a while you lose patience.
What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
So two essential qualities in my view are: being really good, have excellent foundations and being open to learning and coaching if you don't have those.
I used to be more of the former type who would try to power through everything & still display flashes of it whenever I do have to code, but after being a lead engineer for almost a year, I understand more deeply the value of knowledge transfer and making everyone more productive. Having a team that is genuinely happy to work together has an effect of creating more for the company than the sum of their parts because the team is more honest with each other from being comfortable/not having to fear reprisal, which results in better (& planned) team architecture, mistakes being caught as early as possible, and overall decreased stress.
All good developers were less-good junior developers once. What I value most is the good, patient developer that turns all the developers around him into good developers over time. They're far more valuable than someone with a high production rate but who drives others away.
Not always, and "eccentric" doesn't mean "unable to be helpful or kind".
> because they just know more then you and it is hard to explain everything every time
Yes, it's hard. It's a different skill than programming or general intelligence. And it's a harder skill to find or to train. As a rarer skill, it's thus more valuable, and more useful to select for. And as an engineer, developing a rarer skill makes you more valuable, which will improve your career prospects (in both pay and position).
Source: I've been on both sides of numerous performance review processes, and seen what people value at many levels of a technical job ladder.
What if they don't see those things because they're not being communicated well?
>What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
But it isn't necessary that those 3-4 polite junior devs are your opportunity cost. The good developer may well be alienating n good developers, testers, DBAs, Ops analysts, or BAs.
Following simplistic rules like this is usually what leaves us knee deep in the proverbial.
Maybe I've been lucky, but I've never worked with anyone who's as much of a jerk as described in the article. In my experience, talented developers are usually intelligent enough that they can make up for their shortcoming in the social area by consciously adapting their behaviour. They're not "normal" but they function well enough to work with others.
I've worked with plenty of jerk-ish, abrasive, opiniated, "take no prisoners" people who can be very fiery in meetings and can be highly critical of other people's work. Yes, they can be a giant pain in the arse - they're just so damn challenging. But in my experience they're normally challenging because they want the company to do better.
But I've seen many times (mainly in large companies) teams that were populated and led by people who were very consensus-based, had superb social skills, and had a genuine drive to succeed - but didn't because there was not enough fire in the team to make the right choices.
To me, the business of software development is way too complex to apply a simple "no jerks" policy. Brilliant jerks are often to be found at the beating heart of successful software.
I had a frustrating moment the other day where a colleague said that
was more explicit and personally preferred in Python than a literal I realised I was being pedantic but I genuinely believed in "good craftsmanship" when I really pushed him to change it.I need to get better at this because the social friction I caused may cost more than the poor craftsmanship. But the other part of me is thinking, "c'mon man... Seriously?"
Which is why I call it craftsmanship. It works the same for all intents and purposes, but c'mon. :)
It causes calls to strlen and potentially memory allocations. Just use the default constructor!
Compilers can do some pretty fancy things with literals because they know they optimize constants known at compile time.
GCC 7 is available for use now.
Manager-Tools.com speaks very well to relationships being very valuable, worth more than float(5) vs 5.0... though... I really do agree. Float(5)? Really? And 5 should be replaced with IntNoReallyItJustAnInt(5)?? ;)
The other upside is that code reviews are higher quality and design focused.
Does he also prefer to right integers as 'int(float(5))'? The mind boggles, it really does.
Then again, I'm not a software developer (even though I did write some Python scripts for my workflow in the past).
"Good craftsmanship" is both subjective AND hard to relate to an increase business value. Better to stick with third-party recommendations, like textbooks or linters.
FWIW, I'm firmly on the 5.0 side.
Personally I like to go with "is accepted by the community" as opposed to "is accepted by most people in this room" or "Greg thinks it's beautiful".
$ python -m timeit '5.0' 100000000 loops, best of 3: 0.00719 usec per loop
$ python -m timeit -n 10000000 'float(5)' 10000000 loops, best of 3: 0.0771 usec per loop
$ python -m timeit -n 10000000 '5.0' 10000000 loops, best of 3: 0.00717 usec per loop
[timeit] provides a simple way to time small bits of Python code. It has both a Command-Line Interface as well as a callable one. It avoids a number of common traps for measuring execution times. See also Tim Peters’ introduction to the “Algorithms” chapter in the Python Cookbook, published by O’Reilly.
Ref: https://docs.python.org/2/library/timeit.html
Different machine, so the timings are different from above, but here are some permutations:
Float literal:
$ python -m timeit '5.0' 100000000 loops, best of 3: 0.0152 usec per loop
Integer literal coerced to a float:
$ python -m timeit 'float(5)' 10000000 loops, best of 3: 0.146 usec per loop
Float literal coerced to a float:
$ python -m timeit 'float(5.0)' 10000000 loops, best of 3: 0.143 usec per loop
Integer literal:
$ python -m timeit '5' 100000000 loops, best of 3: 0.0152 usec per loop
Float literal coerced to an integer:
$ python -m timeit 'int(5.0)' 10000000 loops, best of 3: 0.155 usec per loop
Integer literal coerced to an integer:
$ python -m timeit 'int(5)' 10000000 loops, best of 3: 0.14 usec per loop
Exhibit 0: Linus Torvalds
It would be nice to see some example of a Jerk and non-Jerk attempting the same strategy.
The thing is both methods, if applied consistently, produce results. The trouble is the jerk method is a lot less efficient in terms of use of human emotional capital.
I think it's successful because the BSDs were under a cloud of legal suspicion in the early '90s (the USL lawsuits) and Mach didn't have zero-copy message passing, and so as a result, Linux was basically the only free software general-purpose UNIX-alike for 386s that existed. (MINIX resisted being general-purpose until 2005.)
Once you have that, it's basically a matter of network effects.
There are a ton of things Linus did right, of course. There are also a ton of ways he could have destroyed the project, but didn't. All of those are praiseworthy. But we have exactly one data point, and I don't think we can extrapolate a rule from that, certainly not a rule that everything he did was right. If there had been Linux and 386BSD competing on equal terms, who knows what would have happened.
Brilliant jerks are, in fact, often to be found at the beating heart of successful software. That is true. But would that software have a different beating heart if not for them? Would it be more successful?
The latter actually harm and exclude people while acting politely; Linus does not.
I have near unlimited respect for Linus. He has an allergy to bullshit. He does not mince words when preventing any kind bad code or needless complexity from entering the kernel.
The same things that make some people consider him an "asshole" are the same things that make him so effective.
If one imagines that intelligence and sociability are merely two of many possible desirable traits, and that top firms with big budgets also see similarly, then eventually those with the highest concentration of desirable traits will be sniped up, leaving firms with lesser budgets to take those with fewer desirable traits of lesser magnitude.
The same can be said about customers. Some customers could be described as "10x paying nice customers", vs "10x paying jerk customers", and these could be thought of as merely two of many possible independently varying traits. Eventually, one might suspect that discerning firms will try to keep the best clients, while pushing clients with fewer desirable traits of lesser magnitudes to lesser firms.
That's orthogonal to the issue mentioned in the article. For the purposes of "not being a jerk", it doesn't matter if that comes naturally or if you have to devote conscious effort to it; only the resulting behavior matters.
> Brilliant jerks are often to be found at the beating heart of successful software.
Survivorship bias. Strange policies or properties are often found in successful companies/projects, who often write up articles about them as though those policies contributed to their success, never considering the possibility that they succeeded in spite of them. The same goes for jerks: some companies/projects succeed in spite of the jerks in (or running) them.
Say what you like about MS's business practices during the 90s, but I think the history shows that a large reason they were able to continue their dominance was because of the unfair and frankly anticompetitive practices that they embraced back then. Bill Gate's willingness to be a jerk was what kept their company on top.
Of course, that was directed productively and outward, not destructively inward.
How ironic.
It's a risky communication strategy, but I wouldn't condemn everyone who uses it.
what kind of person would say that with full vitriolic sincerity to someone they respect? Why say that when you could say, "I strongly disagree for the following reasons..." or something else similarly diplomatic and actually productive?
— Ben
Apparently you do not understand how serious the situation is.We are getting killed killed killed out there. Our current product is radically worse than the competition. We’ve had nothing to say for months. As a result, we’ve lost over $3B in market capitalization. We are now in danger of losing the entire company and it’s all server product management’s fault.Next time do the fucking interview yourself.
Fuck you,
Marc
That kind of bland vocabulary makes one's statements sound like limp static. Corporate dialect is contrived to remove strong (corporate-environment-inappropriate) emotion from your speech. If you're well acquainted with your colleagues, then I'd hope you could express yourself more genuinely. You're probably more relatable than a peppy talking head who never offends anyone.
Emotion is a very powerful signal during discussion. It's a counterpoint to logic; they work together. Rarely does logic by itself win anyone over. Trying to remove "unneeded" (who decides what an unneeded emotion is) emotion is folly. We're not Vulcans.
That is not meritocracy and pretty bad workplace.
Tip-toeing around the issue can make things much worse.
It is much easier to say, "Stop. That's stupid, try again."
Than to try and cherrypick what they've done right, because often times, there isn't anything useful there.
Considering that Gates, Jobs, and Torvalds all have stories where they tell someone what they're doing is stupid, and actually get a decent product out at the end of the day, it doesn't seem like diplomacy is necessary at all.
If you can't say ~why~ it's "stupid," your comment is not useful. And if you do say why it's stupid, those reasons are much more important than the inflammatory adjective "stupid," so just say those instead.
While there might be a correlation, I don't think you can entirely extrapolate between "ruthless business practices" and "toxic interpersonal interactions". You can have either without the other, and I wouldn't automatically assume that skill at one implies skill at the other.
For example, the person who wrote this article, is less of a fit for a cutthroat, decisive, business-minded management position; and might maximize their relative potential (in their current situation and state) by reaching a level that's below any business-minded interactions.(captain of a development team, answers to a manager who isolates them from business/mean/jerkish discussions.)
Edit:grammar
In more ways than one. When jerks are allowed to be jerks, people who do not want to deal with jerks leave the company. So the jerks bubble up to the top, while otherwise great engineers who don't want to be berated move along to better things.
If you encounter many skilled jerks, consider why that might be, and why in the same environment you don't also encounter skilled people who are fun to work with. In such an environment, the skilled people who are fun to work with can afford to leave, while some of the non-skilled people may not have that option. So, it's natural that within such an environment (company, project, etc), it'll look like a correlation between jerkiness and skill. People then start assuming a causation, and thus contribute to that same cycle.
The opposite environment, with many skilled people who are fun to work with, will tend to reject jerks regardless of skill. I've also noticed that such an environment tends to have a much higher degree of mentorship and collaboration, in addition to being more fun to work in, and boosting energy rather than draining it.
See also https://www.youtube.com/watch?v=-ZSli7QW4rg and http://www.slideshare.net/dberkholz/assholes-are-killing-you... .
Often that might be because the viewer is unaware of their own jerkness, and only sees others reciprocating.
It's also a question of circumstance. Right now, for example, I'm working to mitigate, and eventually to resolve, a morale crisis on my team, which exists for good and cogent reasons that don't merit discussion here. Now is not the time for fire - and fire alone in any case works only when the vision is so powerful that smart, capable people will tolerate being driven painfully hard to achieve it. Without offering something to make that worthwhile, fire can't drive them onward - it can only drive them away.
In any case, I'm not trying to argue with you, and I hope I don't come across as if I were. It's just that I feel like there's a strong reaction in this thread to a bias, whether perceived or actual, on the part of the article author and in the direction of courtesy. So my purpose here is to sound a cautionary note, and attempt to keep visible in the discussion what I regard to be the nuance of the matter.
Especially since a lot of engineers default to brusqueness, which I totally understand while finding often counterproductive. It can work in a collegial setting, among secure peers who share mutual respect, but in any other context it just looks like asshole behavior - and that is exactly what it is.
To understand one's audience, and adjust one's persuasive style to suit, is a fundamental aspect of rhetoric, and given the ubiquity of office politics and the necessity thereof - a topic meriting its own essay, which I will not write on a phone - such understanding and adjustment is important to professional success, as well. I think that's something it is easy for us to overlook, because computers only need to be told and then sworn at, not persuaded.
Also, all else equal, it's both more ethically sound and more useful not to act like an asshole. Leaving a trail of hurt feelings behind you is no way to go through life. Sure, we might excuse it in someone with a vision on par with that of Steve Jobs. But no one here is on par with Steve Jobs.
Survivorship bias doesn't render this an ineffective argument against the simple "no jerks" policy argued for in the article.
The contention is "(jerk present) → ¬ (success)", aka "¬ (jerk present) ∨ ¬ (success)". A single case of "(jerk present) ∧ (success)" is sufficient to disprove the direct implication.
The contention in the article is not "you can't ever succeed if you have a jerk on the team" or "a jerk will always cause your team to fail". A property doesn't have to be universal to be common enough to be worth writing about.
So no, a single instance of succeeding despite a jerk does not "disprove" anything relevant here.
That's what you replied to with "but survivorship bias!". And the article itself says:
> A “no jerks” policy must be preached and practiced from the highest levels.
... which is a universal and normative call to action.
If jerks universally led to failure, it would hardly need writing about more than once, as everyone would very quickly have to understand and deal with it. However, because you can sometime succeed in spite of the presence of jerks, that makes it a problem particularly worth writing about.
These are stereotypes, and quite often bloggers will make up stories to illustrate a point. Which is fine, but when your point is based upon stereotypes, then I'm not interested.
----
So with that said, I agree with everything you've said. Quite often these abrasive people are making valid points.
You know those security scandals that hit (Playstation network getting hacked, etc) where you think to yourself "how the fuck did they manage it so badly, because their fuckup wasn't subtle at all.
You KNOW there was an abrasive jerk somewhere in there saying "guys... this is horrible" and he or she got shouted down, shutdown, and/or fired for it.
We should be putting "abrasive jerk" in quotes. The point that was being made by both of us is that these abrasive jerks aren't actually abrasive jerks, they're just going against the grain because it's the technically better choice.
And then they get labelled as abrasive jerks and ignored, and then queue the scandal when people talk about how horrible the toyota code is (for example).
Note that these people did not really bought into his theories and opinions nor were able to follow his instructions - the amount of code review complains would go down it that would be the case. He did not managed to change the culture toward good nor to teach them. His reach was limited by what he was able to micromanage at the moment.
like... every. single. one. of their sys admin team was really that oblivious. Out of all the people they hired, not even one competent got accidentally picked up somewhere along the way, during all the years they were were running that network before it happened.
Or maybe, their sys admin team was acutely aware, but management didn't give them the autonomy to choose to fix it, and anyone who spoke up and tried to push for the issues to be fixed got labelled as "not being a team player", or a "troublemaker", or even ... gasp ... an "abrasive jerk".
And then they got booted, and everyone else learned the lesson and just shut up and kept collecting the paycheck.
And then suddenly they get hacked, and then finally management was willing to spend the money on securing things better.
2.) It is perfectly possible that abrasive jerks were the ones who prevented others to fix the problems. In particular, they could have created a culture where new employee or junior is not expected to accept all criticism but is shut down when he dish it out.
"This is stupid" is not exactly an argument - if that works then your tech seniors are preferring conformity with jerk over merit of argument. It works somewhat when all working with him are juniors (e.g. less likely to see bigger problems), but makes you impenetrable to valid criticism from other skilled people.
3.) You assume that the problem was lack of autonomy from the management. That is possible, but it is equally possible that tech team screwed up on their own. Organizing larger teams is hard and even super skilled techies, abrasive or not, may completely fail once the group is too big to be micromanaged.
---------------------------------------------
Being abrasive and being direct/open is just not the same. Abrasiveness makes people comply, because they do not want to be humiliated by you. Abrasive people are just expecting everyone to be conforming to whatever they think, they do not create an environment where bad processes get fixed. It does not make people agree with you and they will revert back to the original behavior the moment you don't see.
But regular jerks abound at work because they at least don't make you feel stupid and insulted.
And you hit the nail on the head with your experiences. In high school I was neck-and-neck academically with a brilliant jerk. He went to Harvard, is now a millionaire (without inheriting it) and a much nicer person. Competing with him was one of the most formative periods of my life. He made me better, because I learned not to take harsh criticism and hectoring so seriously. Look at what they do (for you), not what they say (to you).
I actually wish there were a brilliant jerk like him in my workplace. But there are just regular jerks.
And of course when you assign them to solo projects they fail. Because they're not very good at software development.
Which confirms your interpretation and labeling of the 'midwit egomaniac'.
The sad part - it is not usually immediately clear which kind of jerk your dealing with, since they behave the same!
Secondarily, it is not immediately clear to an outsider upon observation which is which either...
Summary I drew: There are genuine mental health related conditions that can cause someone to be a jerk AND still be brilliant. When you find that, you have to first separate them off so as not to detract from others work. Secondly if they can't cut it then let them go.
Yeah, that's true. I'd rather work with an honest jerk than a friendly back-stabber.
http://thehustle.co/steve-job-insults
http://www.forbes.com/sites/davidcoursey/2011/10/12/steve-jo...
http://bgr.com/2015/06/18/what-its-like-to-work-for-steve-jo...
Maybe it's just that jerks don't affect you as much as they do other people. And that's great- for you. But for the rest of the team around you, those people are awful. Those people are the reason your best teammates decide to move on to new opportunities.
You should also consider the old saying 'every team has an idiot, and if you don't know who the idiot is, it's you', and double check that this doesn't also apply to jerks. Maybe the reason you haven't worked with a jerk before (and in fact believe brilliant jerks are just the best) is because you are the jerk.
I don't mean to say that as an insult. I was the jerk. I still am the jerk sometimes. It's hard to see, hard to deal with. Maybe you aren't, but it's worth careful examination just in case, no? Otherwise, you're literally making people around you miserable.
Are they? Most devs I know change jobs to work on more interesting projects, to move into a higher level role, to get a pay bump, to move to a more flexible company, etc.
In my experience it is rare for someone to move because of bad colleagues. Bad management? Sure. Bad co-workers? Not really.
Why do you work at companies with so many jerks? Perhaps you are the problem.
This does not mean that mistakes are allowed and things are done by consensus.
The problem with jerks is that they are jerks: people do not like them and it is hard to work with them and that is not good. Nothing else. Sometimes that is ok - but in many cases it is not ok since team and project needs to grow into other areas where that "brilliant jerk" will not be so brilliant.
I'll take the brilliant jerk any day. They can simply deliver in ways that others cannot.
Holy false dichotomy, Batman. I'd rather take neither of them and fill my team with adequate-to-exceptional devs who also happen to be decent human beings.
I'd rather drive a Ferarri.
I disagree on 'adequate' though. I'll take a truly brilliant a-hole over 'adequate'. 'Adequate' means I'm often fixing their mistakes, checking up on them, making sure they stay on track, etc. I'm ok with smoothing over issues from time to time if it means I can let them run wild on the thing I hired them for.
In which case, based on your budget, you'll have to settle with fewer and fewer desirable traits of lesser magnitude, or conversely, based on your budget, you can push more and more less desirable humans to lesser firms; one can imagine thinking the same with customers or clients as well.
You can have the nice paying client, or the jerk paying client, and a discerning firm might prefer nice paying clients over jerk paying clients (but of course, the most important discernment will be over pay), leading their competitors to have to deal with clients with a smaller set of desirable traits.
That extra throughput is also better spent because instead of 4 people discussing how to do things, there's 1 jerk bossing around 2 non-jerks. Cancel all team meetings!!!
Now, make the team size 15. Most of those will be 3x and 2x programmers as well. Seeded with a 5x, two 4x and the village idiot (VI, whom we will peg at 0.5x, just for the Lulz). So, the BJ has the VI kicked out, starts making much neglected changes, and everything seems to be going in the right direction. But then, your rank and file get demoted -1x because they also cannot cope with BJ's rapid changes. BJ might be seen as keeping the boat afloat, but in reality his productivity is neglected by everybody else's fuckups (which are BJ fault, because he cannot be bothered to let the team know what he's doing). 5x and one of the 4xs quit in disgust of the general chaos, and 6 months later, they are back with a competing product and poaching the big team clients.
So, it does not sound as if BJ "delivers" as much as you thought, does it?
I guess not, at least, within the context of your little story.
To be fair, I am thinking of small teams, and I can imagine how their value would decline in larger outfits.
That said, I don't hire people to write CRUD apps either. Truly brilliant people should be working on solving hard problems which lack a general solution, not data layers and library duct tape.
Says who? This has never been my experience. They are tolerated specifically because they deliver. If they're not delivering then why are they still around?
One of the problems in this industry is that a lot of teams have no real measure of their actual productivity. We have scrums and points and velocities, but seldom have any way to know how this actually compares to other teams, or any other benchmarks.
I've been dropped in on teams that had spent long periods (in cases years) creating trivial solutions. They were productive in their own way, generating huge volumes of code, had a great sense of satisfaction about their process and a sense of accomplishment, but what they were creating was a week of work for a single person if correctly built. And they happily enjoy their synergy until they are outsourced or eclipsed by competitors.
Maybe I'm sensitive. I've been "the jerk" before. I once had a coworker complain to HR and my boss because she felt that I was domineering. I was domineering in this case because I had opinions and expressed them to the team, and their opinion and suggestion of a new process was that we should have "opinion roundtables" where each participant gets the same amount of time to talk with a timer, etc, and need to suppress any suggestions or opinions outside of that period. I left that team and organization, and eight months later the team was fired.
That sort of behavior generates a lot of work to the rest of the team - time spend changing the code, time spent discussion opinions and trying proactively writing the code in way that will pass his review. Time spent being confused over why this or that was wrong again (since it was not wrong actually). If those less experienced people feared him, which is likely, they spent a lot of time attempting to anticipate his opinions and preferences (while sacrificing their own opinions and preferences even when they were right).
Moreover, people like him would cause other experienced people to leave. While junior might be fine with being expected to submissively conform to someone elses preferences that much, experienced person wont. "You are doing it wrong" might work on junior, but not on someone who knows that he is not doing it wrong. Anyone who is willing or wanting to take on responsibility would leave.
Yet moreover, he likely regularly shot down good ideas of other people, which would make those other people more passive. It is the same effect as why micromanagement has.
This stuck out to me as I tend to be very critical in code reviews, which I think made other developers uncomfortable. By talking about it though I was able to soften my approach. I was also able to make sure my language came across as reviewing the code, not the developer.
What about people who call "jerks" people who call someone a jerk?
:-D
Avoiding calling someone exhibiting a negative behavior by the accepted label for that behavior is healthier than tiptoeing around and pretending that Hannibal Lecter just has different dietary preferences and that's OK.
My point is that we're all jerks, one way or another, just don't really know it or admit to it, but we know that everyone has done something that warrants them being called a jerk by someone. No one lives a whole life without being called a jerk by someone. I once thought Mother Theresa was a jerk for being so nice. These labels are subjective and inflammatory. and don't help the situation.
If this is true, it sounds like the best option would have been firing the rest of the team and looking for another like him.
It was for writing dial-up internet billing software, essentially grant/deny access and provide hours connected to the dial-in banks. Nothing all that crazy, a pretty solved problem honestly by that point.
I asked them what they were replacing and why. The team lead got super excited and talked about how they were hired on to replace a single guy who had wrote a ~1000 line Perl script that pretty much handled this whole data import job. This guy apparently made the cardinal sin of using moderately complex regex in his tooling, and that was a sign of how incompetent he was and how the tooling obviously needed to be replaced wholesale.
They did not get the irony of this situation whatsoever when I made the obvious statement of why it took an 8 man team over 12 months so far to replace a single dude with a 1000 line Perl script. Absolutely saw nothing wrong with the situation whatsoever.
Thankfully I ended up not taking that job and starting my own company instead :)
I'd take that claim skeptically. But another consideration is that more than half of a team's work isn't code. You have to write the right thing, not just something, and that requires time and communication. So he might have been a 10x coder and a 0.1x communicator – indeed since he seemed to have little interest in interpersonal relations, some amount of his performance may have been due to his own time allocation choices.
Two of those people together would perform very poorly on some projects. And very well on others, depending on the clarity of the project and the amount of technical challenge it presented.
I have come to believe that about half of his enhanced productivity is simply that he's a rock star and management tolerates him (but not everyone else) cut the red tape. In general, every commit has to bee peer reviewed, but he just jumps and ninja edits the code base at leisure. Everybody is supposed to run regressions before commiting, but from time to time, things will stop working and it will be some of his transactions behind it (which is discovered after multiple people could not do any productive work for half a day, trying to figure out what when wrong with their own work instead). If some tool or another is suboptimal, he will just roll out his own and be done with it (leaving the rest of the team to learn how to work with his prefered tools, instead).
Fortunatelly, we have other very strong developers that act as counterweight to him. Unfortunatelly, they also come with their own quirks of character and you are bonded to run into one of their pet issues from time to time.
About 1 out of every 10 ideas was a good idea, but you had to know how to filter out the bad ones. If you said "no" to one of his bad ideas, he'd say that you weren't listening to his input and complain to your manager.
He was abrasive, condescending, and dominated every meeting. If you said anything to management, their response was "Oh that's just Bob, what a crazy, quirky, eccentric guy!" What they refused to realize was that being Bob's peer was very different than working for Bob. What management perceived as a quirk, was a character flaw that made life hell for anyone working underneath Bob.
And to echo other comments, nothing was done about Bob because management didn't want to take responsibility for the culture of the company. Why risk negatively impacting profits by actually managing your employee when you could blame it on millennials being whiny and you believe that engineers are interchangeable?
In reality, no person is "simply a jerk". Each of us sits somewhere on a spectrum of intolerance towards others for one reason or another. It's healthy to learn how to work with people of all stripes – even individuals who can, at times, be abrasive.
It's unhelpful to pigeonhole people and then extrapolate out their actions from there, because for the most part people don't conform to whatever mental model of that stereotype you've built in your head. People are complex beyond imagining.
Besides, what's the author's sample size here? One? Two? It's an anecdote worth relating, to be sure, but I think it'd be better served by leaving the "Brilliant Jerk" bit out, and leaving it as a story about team morale being more important than the contributions of any single team member.
I've seen a lot that socially desirable behavior is evaluated and preferred rather than people doing excellent work. Group dynamics quickly exclude these by creating a consensus of what is accepted and what the goal of the group is. This is especially easy because these brilliant people are always -by definition- a minority,
Grow up, ignore the jerkness, and enjoy the code. Seriously - great developers are so rare anyhow.
And really, if we're in the business of shipping working things on time, do you think it's a good idea to keep someone on who's going to bring down the rest of your team, or drive them away?
There may be teams that can take a jerk, perhaps with a "handler" (in the team).