
Brilliant Jerks Cost More Than They Are Worth - bry
https://retrospective.co/brilliant-jerks-cost-more-than-they-are-worth/
======
abraae
> 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.

~~~
Waterluvian
Hey that's me!

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?"

~~~
andreyz4k
By the way, float(5) is slower, because it creates two objects instead of one.

~~~
hermitdev
One of my pet peeves in C++ is seeing: std::string s = "";

It causes calls to strlen and potentially memory allocations. Just use the
default constructor!

~~~
sqeaky
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.

~~~
hermitdev
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.

~~~
sqeaky
Enabling the optimizations is important too. If you leave it on the defaults
it does a very direct translation to machine code.

GCC 7 is available for use now.

------
endorphone
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.

~~~
watwut
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.

------
analogwzrd
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?

------
EpicEng
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.

~~~
omni
> 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.

~~~
EpicEng
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.

~~~
65827
Well I'd prefer strawberry ice cream, as long as we're talking options here!

~~~
EpicEng
I don't know, I'd take a good candidate at the moment. trying to fill a
position currently.

------
ChuckMcM
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.

~~~
xiaoma
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.

~~~
astrodust
Their personalities could not be more different. Their approach to business
and life are completely orthogonal.

~~~
xiaoma
And yet all ran cultures where jerks thrived in engineering (or sales in
Oracle's case).

~~~
astrodust
Oracle has burned so many bridges they're living on an island of their own
creation.

~~~
hinkley
I thought Larry bought that island from Hawai'i?

------
curun1r
I've met two kinds of "brilliant jerks" in my working life. One is
insufferable and makes the lives of his (it's usually a he) co-workers such a
nightmare that they end up quitting. The other is abrasive but pushes his co-
workers to achieve a higher level. I've even worked with one developer who was
both and, while I hated every moment of working with him, I'm undoubtedly
better at what I do now for having worked with him.

When I see opinion pieces like this, my first thought is always of the book
"multipliers" which put forward (huge over-simplification) that you should
strive to hire people who make their co-workers more productive. A jerk is
often a strong individual contributor who detracts from the work of those
around him. And to that extent, jerks should be avoided. But when a jerk is
also a multiplier, they can drive achievement far greater than what would
otherwise be achieved.

A good example of this is Steve Jobs who, by all accounts I've read, was a bit
of a jerk, was abrasive and demanding, but also pushed his people to achieve
amazing things, not just at Apple, but also Next and Pixar.

If you avoid the brilliant, jerky multipliers, you just might fail in the most
enjoyable way possible.

~~~
notacoward
> I've met two kinds of "brilliant jerks" in my working life.

I think this is a key point, along with ianbicking's observation that jerkness
is often an environmental (rather than innate) phenomenon. Here's a quote many
here might recognize.

"Extremism in defense of liberty is no vice"

Substitute "quality" or "progress" for "liberty" and you might see what I'm
getting at. Some people are just jerks, full stop, end of story. They won't
stop being jerks. They will continue to bring everyone down, so they're best
gotten rid of. However, there _are_ others who can exhibit many of the same
outward behaviors because of context. Most often, the context is that _people
aren 't listening_. In an organization where there's a strong emphasis on
empirical results, and even more so in one where there's a strong focus on
learning, this "situational jerkness" doesn't occur. On the other hand, when
people persist in _doing things that are wrong_ despite every prior proof that
it's wrong, others might get frustrated enough with them to start being jerks.
Examples from my own experience might include:

* Repeatedly deferring fixes to a known serious problem, while resources are devoted to less important things.

* Re-submitting the same proposal or patch without fixing already-identified flaws.

* Persisting in collaborative anti-patterns such as pulling rank or announcing decisions made without all stakeholders present.

I've been a jerk myself, when faced with these kinds of situations. I'd have
to be some kind of jerk _not_ to push for change, when experience tells me
that the status quo leads to a bad place. Sometimes passive aggression needs
to be met with active aggression. When faced with being a jerk for good or a
jerk for evil, I'll choose being a jerk for good. It's not a decision to be
made lightly, and if it happens often then we're probably back in "permanent
jerk" territory, but sometimes it's a decision that needs to be made anyway.

------
alexc05
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.

~~~
throwawaymsft
If you're conscientious enough to ask the question you don't have to worry
about being a jerk :).

------
alexandercrohde
Well, let's look at it from the "the jerk"'s perspective.

How would feel if other people accomplished 1/10th what you did? What if they
got paid 80% of what you got paid too?

What if teaching them took so much of your time that it was faster to do it
yourself than hand-hold them through the process?

What if, despite producing more than the rest of the team combined, management
saw you as a problem, and wasn't interested in your perspective now that you
had a reputation?

Have you asked "the jerk" to be more polite about his feedback? Have you
explained why it's important? Have you listened to his perspective?

~~~
jayroh
You work to raise your teammates up. Full stop. Productivity for a team is in
aggregate - it's the entire teams productivity that's at stake, not an
individual contributor's.

~~~
dasmoth
This seems to be a pretty ubiquitous view nowadays, but neglects the
possibility that some projects might go better with an individual contributor
just getting on with it.

~~~
chillacy
An interesting analogy is the tradeoffs in going from one machine to a
distributed system: a single SQL server will outperform a 3 node cluster for
small loads, but the 3 node cluster will survive hardware failures and
eventually out-scale the single-node setup as you add more nodes.

It feels like larger companies are always reluctant to have a single point of
failure, whether it's a machine in Utah going down or Greg getting hit by a
bus.

~~~
dasmoth
It's a good analogy. Setting up the three-node cluster is an awful lot more
work, and if you don't do it right there's a real chance that you'll end up
with lower real-world reliability than the single node.

That said, I can understand why large companies worry about single points of
failure. What perplexes me more is that the you-always-need-a-team mindset is
filtering down to smaller and smaller organisations.

------
xiaoma
> _" He could crank out 10 times as much work as any of us could in one day."_

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.

~~~
ianbicking
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.

~~~
crpatino
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.

------
mjfl
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.

~~~
jimktrains2
> 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.

~~~
treebeard901
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.

~~~
thomasrognon
The article claimed he was a 10x and that he was usually right in any
disagreement, so he probably built up resentment towards them, too.

------
segmondy
People that lie, who are dishonest, lazy, don't wish to work hard and look out
for their interest before the company's interest are the worst kind of jerks.
These jerks are seriously threatened by any kind of person who is not afraid
to speak up and call them out to their shenanigans.

I've seen this before, where the team was building a skyscraper with cardboard
boxes, and the "brilliant jerk" called them out and they fumed and morale was
low. The jerk left and the team supposedly started meeting their goals and was
releasing faster.

Well of course they were! the lone voice that was the gatekeeper was gone and
all sorts of garbage was being committed to the code base. The skyscraper went
up faster, and one day it came crashing down never to go up again. I was a
consultant that saw this. So I always take "jerk" with a grain of salt. Of
course, people should be kind, diplomatic, and caring, but they should also
tell the truth and the bitter truth. I'm conflicted on the entire training
thing, I believe that senior developers should teach, however, unless the
company is willing to budget time for that, it is on each person to learn and
shore up their skill. The company should train their developers if they are
not up to par.

Work is were work happens, if you wish to learn and grow, study furiously
outside of work. It's your responsibility as someone that represents
themselves as a professional and asks to be paid a fair wage to learn. Some of
these lessons the "senior developers" can teach are worth hundreds of
thousands or millions of dollars, I don't see junior developers cutting checks
to them for those lessons. Let me reiterate, work is were work happens. If you
are fortunate to find a mentor that is willing to teach you, be grateful for
you are blessed. If you apply for a job and the company never talked about
training you, it's your responsibility.

------
spacemanmatt
The only "10x" developer I have worked with taught me not only a ton about
agile teams, but also about the liberal use of interpersonal skills in
advancement of that goal. We routinely worked with education administrators
(former teachers) who all had classroom experience and professional
interpersonal skills training.

It was amazing to work with people you could simply expect respect from, even
when everyone was well aware of the simmering annoyance and disagreement
available below the surface. You just can't build the kind of momentum we saw
with people who many any team member feel unsafe in their role.

~~~
gydfi
I don't believe in 10x developers, but I've seen a lot of 0.1x developers.

~~~
spacemanmatt
I believe I caveated the term enough by putting "10x" in quotes. I don't
strictly believe in it either. This guy was great at organizing a team and a
full-stack project back when distributed apps on a pure OSS stack was still a
bit of an accomplishment.

------
bagacrap
"Where a normal review would often contain a handful of comments and
suggestions, he would regularly end up in the hundreds"

geeze. This is either a ridiculous hyperbole or telling of a more deep-seated
problem. You should not regularly be posting changes that have room for
hundreds of comments, and if you do post a change that massive, it should not
be considered normal to only elicit a "handful" of comments/suggestions.

I work in a company with a strong code review culture. When I'm less confident
in the correctness of what I'm doing, I'll ask for a review from someone who I
know will use a fine-toothed comb. This necessarily means dealing with what
seems like personal preference, but that's a small price to pay for added
assuredness you're doing the right thing. Some reviewers pretty much just
rubber stamp your work. That can be useful if I'm highly comfortable with the
code I'm working with, but overall I don't think that is a positive or makes
them less of a jerk. If anything, not taking the time to provide meaningful
feedback is the jerk move.

------
latenightcoding
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.

~~~
phaed
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?).

------
cateye
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,

~~~
st3v3r
This is just a strawman. No one is suggesting that you should hire mediocre
people instead.

------
hug
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.

~~~
novembermike
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.

------
technologyvault
It's never fun to have a jerk on your team, no matter how good he is at what
he does.

True brilliance includes the ability to recognize and govern how you are
affecting others.

------
dimgl
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.

~~~
watwut
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.

------
w00tw00tw00t
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 ;-)

~~~
wott
> to call anyone a "jerk" is something that only jerks do

What about people who call "jerks" people who call someone a jerk?

:-D

~~~
w00tw00tw00t
recursion limit of 0 on this stack!

------
Exofunctor
It's hard to be unbiased while being introspective, but I suspect I might be a
bit of a jerk. I don't berate people, but I get frustrated easily with what I
consider to be manifestly stupid choices. It's worth noting, then, that the
most successful and productive teams I've worked on have been where
_everybody_ was a bit of a jerk. We could give each other shit without our
egos getting in the way. We knew that it was just banter. It's kind of like
how guy friends rib on each other all the time without it hurting their
friendship; there's a certain baseline level of criticism that's enough to
convey useful advice but not so much as to make people feel like shit. E.g.
"Kenny, what the fuck is this loop supposed to do?" Is more effective than "I
feel like this could be written more clearly."

------
bdueicnen
Brilliance is not universally recognized. That is, in this case, very few
people can accurately evaluate a programmer's skill.

Previously, I thought myself to be exceptionally good at my craft, and I let
that define who I was as a person. Recently, however, I reconnected with an
old, vagabond friend. No one in his circle could evaluate my programming
competence or even cared about it. To them, I was a socially awkward, single-
dimensional guy. That really shattered my bubble.

------
ianbicking
I don't think being a "jerk" is a personal trait, it's an environmental
result.

Sometimes people are very picky because they are trying to stonewall you. They
come up with review comments that might be accurate, but aren't actually
intended to help the change land. Maybe they review just far enough to veto,
and then you fix that and they review enough to veto again. That kind of jerk
is not worth much, but it's the malintent behind the impolite behavior that is
the problem. Often the person is disengaged and disinterested in their job.

Sometimes people are become defensive and difficult because they don't believe
they are contributing enough compared to their past performance. I've seen a
lot of people who did a lot of good work in the past, but aren't doing well
now. Maybe processes changed, maybe how the team makes priorities changed,
maybe technologies changed, maybe they aren't managing themselves well, maybe
they are just depressed and having a hard time functioning. Maybe it's
compounded because their own displayed confidence backed them into a wall, and
they can't admit there's something they don't know or aren't able to do, and
so they can't learn to do it. These jerks are "essential" (because they know
stuff, maybe have authority), but not productive. Sometimes they stonewall to
hide this.

There's jerks who have their own agenda that doesn't align with some of the
people they are supposed to work with. It a matrixed organization everyone
_validly_ has independent agendas that cross with each other. Maybe they only
feel personally responsible for product quality, while they are a gatekeeper
for people who are supposed to deliver new functionality. Because of how
authority may be setup, someone may feel trapped between two authorities
(their boss and this gatekeeper) with no way to come to agreement on
priorities. Usually this is a lack of understood overarching priorities from
leadership. Sometimes without that in place the only way to "win" is to be
difficult.

Personally I don't have a problem working with abrasive personalities so long
as we truly share a goal and are working towards it. Having a group of people
who really share a goal is not as common as one would hope.

------
pipio21
I have created some companies and managed lots of people.

In my experience, the moment I hear someone calling someone else "jerk", it
tells me more about the person telling it than about the "jerk" itself.

In particular it tells me you as manager can't handle this people, and you are
incompetent as manager and need to improve you handling people's skills.

It is something similar to Cesar Millan working with dogs, but instead of
Cesar visiting dog owners that do not have a clue about the dogs they have,it
is a similar process with people. I am somewhat of a "natural" managing people
but also studied practical phycology for years in order to understand and
manage different people and I can testify that most managers are so clueless
in the practical side of things(they probably studied the things they don't
apply in practice).

A "no brilliant jerks" policy is the best thing you can do for your
competitors that know how to handle them. Call it "Always live in your comfort
zone""Do not learn" policy. Go for it.

I personally love to welcome those jerks in my company and fix their traumas
with clueless managers. It is also very profitable, you make money doing good
and feels very satisfying at the end(after the work of fixing the traumas).

~~~
falsedan
Hey, you sound like a jerk:

    
    
      - stating your opinion as fact
    
      - not trying to mentor or give learning opportunities
    
      - relying on being 'right' (I'm rich and successful because I manage jerks the right way)

------
new_hackers
I was a jerk at my last job (btw, I'm not saying I'm brilliant either). It
ended up costing me and I was shown the door. However, I was picked up by some
former co-workers that knew I had some talent.

Now I actively manage my "jerk" tendencies. While I still have my jerk
moments, I think my co-workers realize that I'm trying not to be a jerk so
they let it slide. And when I am being a jerk, they will call me out on it.

------
ender7
People responding about how they personally aren't bothered by jerks are
missing the point. It's great if _you_ have thick skin, but it's hard enough
to hire quality engineers without having to stipulate that they must also be
psychologically hardened against lazy, petty, or oblivious aggression from
coworkers (i.e. jerky behavior).

If I can choose to hire one brilliant jerk or three merely "good" engineers
who don't need to be reminded to treat their coworkers thoughtfully, then I
take the three engineers every time.

Arguments pointing to famous productive jerks (e.g. Linus Torvalds) also miss
the point. Sure, Linus's prickliness may actually be a benefit given his
singular position, but it's just that -- singular. You'll notice that no one
else in the Linux dev community gets lionized for their random acts of rage.
The world can tolerate a single Linus, but the solution doesn't scale,
especially not to a random work group at a tech company.

~~~
crpatino
There's room for exactly one hyper inflated ego in the Linux kernel
development team. If you are not Linus, you are 25 years late.

------
achikin
"Hatred is the coward's revenge for being intimidated." ― George Bernard Shaw

------
ahallock
This post is full of contradictions and vagueness.

> Its[sic] not that he was wrong — he rarely was

> He had good reasons, and he was more often right than not

> He just stated his opinions as fact. It was clear that he saw the world in
> black or white — no gray areas — and we were all wrong.

So the author agreed that he was right almost all of the time, but he should
allow for gray areas? Makes no sense.

Later on:

> A funny thing happened almost immediately after he left: morale increased
> steadily and we actually began to meet our goals even faster with one less
> person on the team.

But the "jerk" was always right and "slaughtered" the code reviews of his
peers, so what kind of code were they producing to meet their goals?

Maybe this guy was a jerk and didn't work well on the team, but it also sounds
like the other people involved were terrible at their jobs and should either
get re-educated or find another career.

------
ImTalking
Been there. Was involved in a telco software project where one person was a
genius, a true unicorn. We were in meetings where some of his insight and
perspective left us scratching our heads in amazement. Yet he was the most
destructive co-worker I've ever come across.

He never did anything. He would belittle others if they didn't grasp things.
He would see a well-layout project plan and laugh and say that he could do it
in a weekend, and management would listen because of his intellect and
dominating presence. Every request for him to actually do any work was met
with a 'too busy' answer, yet he would berate others for not meeting
schedules.

~~~
antisthenes
So what's the best way for people like that to apply themselves in your view?

~~~
ImTalking
Despite his intellect, he was a child really and his only hope was for
management to rein him in and focus on deliverables (which they did not).

------
rch
I worked with a brilliant jerk. He's a MD PhD w/ a 160+ IQ, sometimes yells at
colleagues in meetings, and can do things nobody else can do. Wouldn't trade
the experience for any I can think of.

------
GoToRO
So why he was a jerk? "Where a normal review would often contain a handful of
comments and suggestions, he would regularly end up in the hundreds. Most of
the comments were opinion and personal preference."

So he saw more problems in the future than the rest of you and maybe your
comments about his comments are opinion and personal preference. How do we
know the truth?

Anyway, this article is a proof that indeed B players never hire A players.
Because they don't get it and they take everything personal.

------
brendangregg
Netflix has a "no brilliant jerks" policy in the culture deck[1], which people
are encouraged to read when applying to work here. The policy works great.
Just because some brilliant people are jerks doesn't mean all are.

[http://www.slideshare.net/reed2001/culture-1798664/35-Brilli...](http://www.slideshare.net/reed2001/culture-1798664/35-Brilliant_Jerks_Some_companies_tolerate/35)

------
whack
Two obvious counter-examples: Steve Jobs and Linus Torvalds.

10x programmer who says what he thinks, gives brutally honest feedback,
doesn't couch his facts behind euphemisms or nice-guy behavior, and has
extremely high standards for code quality? To many people, this description
fits Linus to a T.

And even if you dispute the characterization of Linus as a jerk, Steve Jobs
certainly was. I don't see how anyone can hear stories about the way he treats
his colleagues and employees, and not admit that he's a jerk.

Did Linus and Steve cost their respective organizations/missions more than
they contributed?

I think a more balanced answer to the value of jerks is... _it depends._ Some
brilliant jerks, if put in senior enough roles and given sufficient influence,
can produce outstanding work-product. Outstanding enough to justify the loss
of morale and attrition all around them. But if you're going to hire a jerk
and expect him to be another cog in the machine, he's much more likely to gum
up the works instead.

Some roles require rare and outstanding talent above all else. And other roles
require someone who can follow orders, work well with others, and not rock the
boat too much. Whether or not you should hire a brilliant jerk, really depends
on which type of role you're hiring for.

------
errantspark
It's less likely that there's a team of people who are abnormally sensitive to
criticism than one person who is uncommonly abrasive. In this case likely the
jerk's output was not worth his externalities.

In general I think the externalities of having "No Jerks" tend to put a cap on
an organizations success. While they can be tough to deal with they challenge
the status quo. This is key if you are to avoid local maxima. In abstract a
company is a hill climbing algorithm in the space of success; without noise in
the system you are very likely to get stuck in a local maximum. Too much noise
and you might never climb.

It's not necessary to be a jerk to succeed, and it's not necessary to be a
jerk to fight the status quo. I do however feel a strong correlation between
these traits and being a jerk. It's all well and good to search for the right
people to perfect the mix but you'll always have to settle eventually, don't
be afraid to settle on someone who's a little hard to get along with if they
add something else key to the mix.

Simple rules are useful because they're easy to follow; but all rules have
externalities. If you're following "No Jerks" to the letter I'm not sure
they're are worth it.

------
elgenie
The thesis being argued here isn't supported by the poor anecdata.

> Every time one of us would post our code for review, he would slaughter it.
> Where a normal review would often contain a handful of comments and
> suggestions, he would regularly end up in the hundreds. Most of the comments
> were opinion and personal preference. He had good reasons, and he was more
> often right than not, but he never even tried to be kind. He never took the
> opportunity to teach or mentor. He just stated his opinions as fact.

> [...] At first the rest of us tried to have constructive conversations, then
> we often just gave in, then I realized that we were actively avoiding him
> altogether and skirting our process. [...] He was so good. Was it worth even
> arguing or talking to our manager about him? Surely if we just put up with
> his attitude, we’d accomplish more because of the sheer volume of his
> contributions.

The solution here is indeed to talk to the manager. A brilliant jerk with
strongly held opinions about code should be pretty easily convinced based on
efficiency grounds. Repeatedly leaving hundreds of detailed review comments is
not a good use of time, while writing up something that could be referred to
that explains the reasons for the coding standards would prevent such comments
from needing to be made in the first place (and could be used by others to
distinguish stylistic preferences and opinions from truly necessary
standards). Repeatedly having the same "constructive conversations" is an even
worse use of time.

While I'd question the "brilliance" of somebody stating "opinion as fact",
someone leaving hundreds of comments in a code review clearly __cares __and
thus can be reached by an argument grounded in the things he cares about.

------
altoz
If he really was a 10x engineer and it was a "small team" (say 6 people),
wouldn't firing the other 5 have been the better move?

~~~
Arwill
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.

------
athenot
Maybe it's just me but most truly brilliant people with whom I've worked, have
been the opposite: very nice. They were not only smart in their own field but
also smart on an emotional level. They were the kind of people you wanted to
be around, and they were constantly learning from other brilliant people,
recognizing that a bad personality creates friction to learning.

~~~
achikin
Maybe that is because you're positive and open-minded enough to concentrate on
their good qualities and not to perceive them in passive-agressive way as
'jerks'? :)

------
DesiLurker
IMO the 10x productivity thing is a bit of straw-man. thats rarely the case.
but realistically its more like 3-4x. I'd include one crucial factor in
evaluating this that I always look for in new hires, its Ownership! Do you
have commitment to your responsibilities or is it just about finding immediate
gain (could be ego for brilliant jerks or security for mediocre lazy bum). IMO
in long run if you are about avg you will converge on the 'right' solution if
you are looking for it. the problem IMO is many engineers have weak sense of
ownership of what they do & based on their capabilities they adjust their
behavior.

I'd factor in the motives behind being jerk before judging. Is it that they
are just mean egotistical person whose using his technical superiority or
there is genuine desire to make things better even if it means 'breaking a few
eggs' in short-term?

~~~
watwut
I worked with someone like that once and it made me conclude it does not
really matter whether the intention is good.

If code review forces you to adjust hundreds tiny details according to someone
elses preferences and opinions (as opposed to when you have something really
wrong), you can not take ownership of that code. Because it is not your code
in the first place. If you want people to take ownership and responsibility,
you need to allow them to do so - not really possible when top dog is
micromanaging them.

Imo, the developer in question should have work alone on some core part of the
project he would have responsibility for and not do code reviews frequently.

------
mirekrusin
Funny that he complains about "jerk" seeing world as black-and-white in
article that categorises people as jerks/non-jerks without any mention of in-
betweeners.

Also what if the "jerk" is actually right? What if he is truly surrounded by
incompetent people and needs to push things himself, repeating himself all the
time, his suggestions being ignored or simply not understood or completely
outside of intellectual capacity of his colleagues? What if perceived progress
after firing him is illusory. Created by banal steps and pseudo milestones.
What if the "progress" in few years perspective will mainly mean running in
circles without adding any real value, just code debt?

Good manager wouldn't let go person like that, he can always jump into R&D,
creating prototypes of systems/ideas alone or with somebody matching his
competence.

------
funthree
I don't like to defend a jerk anymore than the next person but I can play the
devil's advocate here.

If he's a 10x developer he's going to be a genius. A genius is a person who
sees the world in shades of grays. He can't help it. If he's of that caliber
then it's built into how his brain works. The comment about him being both a
10x developer and someone who sees in black and white is generally off.
However, if he's looking at the work of an average person or even just an
above-average person, he will ten to be able to see stronger shades of grays
than other people because of his high aptitude. This is possibly why he
appears to be someone who sees in black and white.

Overall the author of the article borders on anti-intellectualism... which can
easily veer over to anti-semitism.... the frequent opponent of Linus Torvalds.

------
kibwen
For whatever reason I feel like there's an unspoken assumption in our industry
that a dev is brilliant iff that dev is a jerk, which is clearly false (I'm
sure everyone here has worked with devs who were brilliant at both coding and
social interaction). Note how the article has to explicitly say "it is
entirely possible to be extremely passionate (and even brilliant) without
being a jerk", as though this were some rare intersection of talents. But
brilliant non-jerks get to choose where they want to work, and they're going
to prefer not to work with jerks. If you need really need a bulletproof
business excuse to convince you to tell the assholes on your team to cool
their jets, then do it so that you have any chance of attracting non-jerk
talent.

------
69mlgsniperdad
The jerk referred to in this article should probably be tasked with more solo
tasks. That is the solution. Not to get rid of the jerk, but to give them more
freedom and distance from teammates. A person like that should also have more
say in what they are working on, ideally, I think.

------
aviraldg
The other side of this is worth considering: I'm no 10x developer, but I've
recently been the only developer with some experience working with a team of
others with none (interns.) Simple things that most with more experience would
take for granted, like version control, must be explained at length to a
beginner. Do this enough times and it's easy to skip explaining things,
prompting such articles from them.

Sometimes, before you can realise the factual superiority of a
process/technique, you need to trust someone else's opinion on it. It is only
later that you can understand why. This makes sense to me, because this is how
I learnt when I was starting out.

------
cthalupa
I don't think there's a causal relation between brilliance and jerk level,
but:

It's a sliding scale. Does the contribution of the jerk outweigh the loss of
contribution from people offput by his attitude?

Linus is a jerk, and while Linux might have been even more successful if he
wasn't, that isn't who he is. Should we ignore the success of Linux just
because the original creator can be an asshole at times?

I'd much rather work with a brilliant nice guy than a brilliant jerk, but
sometimes you don't get that choice. Sometimes your choice is a brilliant jerk
who has the vision, drive, and ability to succeed at whatever your goal is,
and a nice guy who doesn't.

------
stillsut
There are two types of "jerk but productive" and what separates them is
whether they are willing, even on the lookout, for things to learn from their
more junior colleagues. Example:

Un-curious jerk: please don't write anything, even developer tools, for this
company is node.js; I heard it's still riddled with bugs and I wouldn't touch
it with a ten foot pole.

Curious jerk: we can't build any official tooling with this stack yet, but for
a couple minutes could you show me how you were taking advantage of the
asynchronous capabilities, I heard it has killer support there?

------
phs318u
I wrote about a similar problem a couple of years back. I called it the "hero
anti-pattern".

[https://mikeseablog.wordpress.com/2015/02/26/the-hero-
anti-p...](https://mikeseablog.wordpress.com/2015/02/26/the-hero-anti-
pattern/)

While I'm sure we can all come up with use-cases where the pain of a genius
jerk is outweighed by the potential benefits, it's worth always remembering
that realisation of those benefits is the very thing that the jerk jeopardises
through his/her bad behaviour.

------
avip
We're in the business of shipping working things on time. I'd take the
"brilliant jerk" over most alternatives.

Grow up, ignore the jerkness, and enjoy the code. Seriously - great developers
are so rare anyhow.

~~~
st3v3r
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?

------
Mikho
When the whole team feels uncomfortable as a result of one person behaviour,
it's time to get rid of this bad apple—total output will be bigger than one
person being brilliant and the whole team unproductive.

For 10 years I had outsourcing studio and once one of my programmers was that
bad apple. At first he was nice, but then in couple months showed his real
character. After four months of pain for everybody I fired him. Never again
would I tolerate such situation.

------
mjevans
It's difficult to tell from one single viewpoint.

However what I find MOST revealing is that there is precisely ZERO mention of
'training' anywhere in the article.

Did they not attempt to train the 'jerk' to be less harsh while still
effectively communicating?

Did they not attempt to train the possibly overly-sensitive employees to step
back and try to not take everything as a personal attack?

I think that /both/ things would have enriched the value of their employees.
Both those who need more guidance on being better at communicating and those
who need to improve their technical skills.

------
funkymike
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.

------
kbuchanan
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.

------
emmelaich
See also this discussion in response to an article "Emotional Intelligence is
overrated"
[https://news.ycombinator.com/item?id=8389065](https://news.ycombinator.com/item?id=8389065)

and let me dupe my comment to that:

Without falling on either side of the debate, it's probably a good time to
bring out this quote from 1704.

    
    
        "Good engineers are so scarce, that one must bear with their humours"
    
        - Lord Galway, 1704

------
solatic
Articles like this one are counterproductive for not trying to understand the
root core of the "jerk" behavior.

There's no such thing as a team where everyone on the team is on the same
level - there's always some distribution, this guy has decades of experience
and is brilliant, this guy is a junior straight out of college. To every
brilliant person on a team (and every team has someone who is relatively
brilliant, again because it's a distribution), the people at the other end of
the distribution are dead weight. The question is about the personality types
of the people on the team and the way that management decides to deal with
them.

If management doesn't put the brilliant people into more senior roles, where
they are directed to mentor lower-performing people to try and bring the
entire team up to a higher performing level, then management is backing the
status quo. This breeds frustration and resentment on the part of the high
performers.

If management does get the high performers to mentor the low performers, but
low performers fail to show improvement, it's management's responsibility to
ask why? Does management need to help guide the high performer to help him
become a better mentor? Or is the low performer a low performer not because
he's inexperienced but because he has no drive for self-improvement? If the
low performer remains a low performer over time, why is management keeping him
on the team?

Too much management philosophy is falsely dedicated to "feel-good" practice.
If your team feels good, then they will be motivated to work for you, and will
work at their maximum potential for productivity, and succeed. Team happiness
is, of course, important, but so many happy teams fail because happiness is
not a cure for mediocrity, and their mediocre products are outcompeted by
better options on the market.

What management really needs to ask is whether brilliant jerks are jerks
because they enjoy belittling others, or are they jerks because they're
frustrated at the team's mediocrity and genuinely desire for the team to write
better code? If it's the former, then yeah, get rid of them, they're toxic.
But most of the time it's the latter, and their the blame for their
frustration lies not with the 10x programmer, but with the manager, for trying
to inculcate happy teams instead of productive and effective teams.

------
phaed
Sure I bet management goals are met in the short term, but you have to wonder
at what level of quality now that they are left to their own devices. Fixing
defects after release is 10-25x more costly than if found during construction
(McConnel 2003 - Code Complete). How much do you want to bet that removing
that brilliant dev that was finding all the issues is going to cost that
project much more than they realize.

------
johnnyhillbilly
So, the specifics: \- The guy takes his time to offer high quality advice \-
The guy offers a lot of high quality advice \- No real specifics are given on
_why_ he's a jerk \- Higher throughput is taken as a proxy for better
performance without accounting for quality, NFRs etc.

This piece - while interesting - doesn't give the information necessary for
the reader to arrive at an independent conclusion.

------
urahara
Definitely. Still the case in the post represents a very soft version of the
type, comparing to who you can really come across at work.

------
JoeAltmaier
Lots of thoughts around the code review issue (the jerk generated 'hundreds of
comment').

I have a rule: the only comments I make are about improving the correctness of
the code. Nothing about technique or approach or format or cleverer ways of
doing anything. Just directly actionable constructive comments.

~~~
hinkley
I try to limit myself to being no more than 50% of the comments on a review. I
know what that probably sounds like, but with experience, and especially if
you study ergonomics like I do, you learn that certain patterns of code that
look OK are actually accidents waiting to happen. This bizarre pattern you're
using has caused 3 regressions already, and we are not interested in there
being a 4th.

To keep it to a dull roar, I do a number of things. Be consistent, prioritize,
shop my concerns, and never go first.

By consistently bringing up your top concerns eventually they'll disappear
from the code reviews, or others will start making the comments before you
can. As things improve you can start bringing up lesser, or deeper issues. If
things don't improve you start asking your peers for help communicating the
importance of the issue. By going last you let other people contribute,
demonstrate consensus, cover issues so you don't have to be the messenger, and
you know roughly how many comments the code is going to get.

~~~
JoeAltmaier
Wonderful technique! Its essentially 'mentoring the crowd' by constructive
participation and modeling good social behavior.

I have used a technique learned early on when I was a young jerk. Instead of
arguing with folks in a group, I would sit one-on-one and discuss an issue
(e.g. how are we going to structure the new project). I would start with a
savvy experienced team member (ok John McGinty was his name) and get a
consensus between us.

Then I'd go to the next team member, and say "John thinks we should do this:"
and say what we had come up with. Not "I think" which is confrontational;
"John thinks ...". Now they've got to put their thoughts up against his, which
most folks can do without getting emotionally invested.

Anyway, iterate until the team was on the same page. End result: I get my way.
Or I get convinced there's a better way. Either way, I win and the team wins.

~~~
hinkley

        I have used a technique learned early on when I was a young jerk. Instead of arguing with folks in a group, I would sit one-on-one and discuss an issue (e.g. how are we going to structure the new project). I would start with a savvy experienced team member (ok John McGinty was his name) and get a consensus between us.
    

I used to do that and it worked very well. But then they took offices away and
now every idea gets shit on before you or they can even articulate it fully.
Now I have to wait until the mistakes have been made - repeatedly - and
discuss alternatives in retrospectives.

------
partycoder
The book "The No Asshole Rule" covers this topic in length.

Not all jerks necessarily brilliant, productive or successful. But the
"culture ruining" jerks are the ones that become an example for others to
follow, or sabotage people with potential to make room for themselves or their
friends.

------
eonaniis
I've worked with people who think mocking the personalities of developers is a
form of team-building. The toxic competitiveness is seen as some kind of
incentive for personal growth. Football players are paid to win, not growl.

------
bry
Also relevant: [http://www.inc.com/jim-schleckser/why-netflix-doesn-t-
tolera...](http://www.inc.com/jim-schleckser/why-netflix-doesn-t-tolerate-
brilliant-jerks.html)

------
fuzzy2
It's all about chemistry. Without it, work isn't fun. In this case, removing
him helped restore it, so that's good.

There may be teams that can take a jerk, perhaps with a "handler" (in the
team).

------
d0ugie
"Brilliant jerk," hmm, the term I always had in mind for our CSO was a
brilliant sadistic sociopath. I couldn't help but admire him, but man, he
loved to ruin my weekends.

------
manigandham
There are just as many, if not more, situations where it's the rest of the
team that actually can't handle the so-called "jerk" by being overly sensitive
and defensive.

------
desireco42
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.

~~~
JoshTriplett
> 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.

~~~
desireco42
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.

~~~
JoshTriplett
> 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.

------
peter_retief
Opinionated people can often be jerks, they don't work well in teams, but that
quality might be what makes them exceptional. Maybe let them work the night
shift :)

------
js8
This discussion is a little bit too abstract. So I am going to take advice
from Richard Feynman (who famously asked philosophers about a brick), and ask:

Was Richard Feynman a jerk?

------
ar15saveslives
If the guy was so good, why didn't they promote him?

~~~
falsedan
Individual Contributors gotta contribute individually

------
comments_db
Can confirm - it's true. I was one few years ago, made conscious effort to
cleanse that attitude of mine. Feels so much better!

------
wott
If I sum it up:

1\. They did not manage to improve themselves a bit thanks to "the jerk"'s
remarks, since the number of remarks (that he calls justified remarks) did not
decrease.

2\. They are now happy to deliver quickly. They don't give a fuck about the
fact that they now deliver shit, and they are happy with the fact they didn't
learn anything.

------
dbg31415
So what is a jerk? I know this article is probably a fictitious rather than
about a specific individual, but seems like if he really was a "10x"er he'd be
an asset to the team and reasonably intelligent people could see that.

This guy was communicating the best he could... "Where a normal review would
often contain a handful of comments and suggestions, he would regularly end up
in the hundreds." Sounds like he's trying. I assume it takes a lot of his time
to generate comments like that... if he was right, I'd want the team to be
following his advice and that should help reduce the number of comments review
over review.

To me... a jerk is someone in legal who says with a smile, "Sorry we were
holding that information about us acquiring that other property until now...
and we need the new system up and running by Monday." Or someone on the design
team who just refuses to switch his designs from points to pixels or pixels to
points or whatever it is the current site is using and then bitches about how
it's 1/2 a pixel off in production. Or that guy in sales who tells me that the
product is shit because we haven't built the one feature his important
prospect really wanted... Someone who doesn't care that they are making more
work for me, someone who doesn't care about the job I have to do.

Someone who is doing a huge code review... with copious amounts of feedback...
man, I'd love that! Sounds like he really cared and is being quite thoughtful.
I think with the right manager and process the team could improve.

Management layers exist to help setup processes that act as lubrication -- so
if someone is just good at his job and rubbing people the wrong way... that's
100% a management problem.

Having dealt with this exact problem in just about every position I've had as
an adult... I think the solution is to pull aside the offended people and make
sure they know how I see them -- I'd explicitly point out what I agreed with
and offer praise about their production where warranted. I'd encourage them to
parrot back some of the behavior towards the offending person... if they
didn't feel comfortable, they could let me do it for them.

I'd pull aside the "jerk" and bluntly as I could explain why it's important to
be more political in dealing with others on the team. I'd make sure some
personal issues weren't going on and that he knew it wasn't appropriate to be
mad at people at work because his wife left him, etc. I'd make sure we did
reviews every sprint (or at least every cycle) where others got to review him,
and I'd read those back to him. I have literally never found a "jerk" who
couldn't be reasoned with, or explained away. I had one amazing dev who was
pretty far down the Asperger spectrum who loved calling people a "fucking
dumbass" and eventually it just became part of the culture on that team to
lovingly call everyone a "fucking dumbass" \-- we even had t-shirts made.
Looking past what is said to the intent... most "jerks" aren't trying to hurt
feelings, they just take pride in their work. Give me people who care any day,
we can find a way to work them into the team.

Be careful that "morale increased steadily and we actually began to meet our
goals even faster with one less person on the team" isn't just diminished
expectations in disguise.

------
snarfy
It sounds like you just fired Steve Jobs.

------
TheOneTrueKyle
I have never had a good job. Most of my life has been miserable working in QA
and not finding any value in anything I do or being able to find something
better.

This currently leads me to where I am today, working at a huge corp in a pool
of mediocrity. The people around me have absolutely no big ambitions to do
anything meaningful in life and are very comfortable with their mediocre kids.
These people are happy which is a whole other topic that blows my mind.

Because I am constantly around these people, they think of me as mean and
condescending. No I am not, I just can't be happy producing shit work in a
company that doesn't provide me with any value. When I go home, I am not going
to have fun, I am going to work on a project that can help me get away from
these people. I don't allow anyone to passively say "tgif" or "its monday" to
me as if I agree with their mediocre sentiment.

Maybe I am mean and that is why I can't find work, but I rather be mean than
mediocre.

~~~
watwut
Are you sure you are not projecting your own attitude on them? I know testers
who like that job. Not like as "I want to become famous", but like as "I
actually like doing that activity and like people on that job".

To address the personal attack in second paragraph: Some of those dudes might
consider their families meaningful. It is goods for kids when their parents
love them even as kids are average - most kids are average so it is good when
parents are comfortable with them. There is nothing wrong nor shameful about
men being comfortable with their own children. Fathers are as important for
children as mothers.

~~~
TheOneTrueKyle
What does your comparison about mothers and fathers have to do with anything?

