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.

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.

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.

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.

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?

    To: Marc Andreessen
    Cc: Mike Homer
    From: Ben Horowitz
    Subject : Launch

— Ben

    To: Ben Horowitz
    Cc: Mike Homer, Jim Barksdale (CEO), Jim Clark (Chairman)
    From: Marc Andreessen
    Subject: Re: Launch

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.

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.

How ironic.

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

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.

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.

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.

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.

Exhibit 0: Linus Torvalds

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.

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 had a frustrating moment the other day where a colleague said that

  float(5)

  5.0

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

The other upside is that code reviews are higher quality and design focused.

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.

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

Does he also prefer to right integers as 'int(float(5))'? The mind boggles, it really does.

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

Then again, I'm not a software developer (even though I did write some Python scripts for my workflow in the past).

$ 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

Yeah, that's true. I'd rather work with an honest jerk than a friendly back-stabber.

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.

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.

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.

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.

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?

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

I'd rather drive a Ferarri.

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?

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.

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.

Thank god I dont work there anymore!

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.

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.

See, the first guy is just a Junior Brilliant Jerk. He's slowly learning and will eventually turn into the Senior Brilliant Jerk if you give him enough time. The Senior Brilliant Jerk is the one that stays just within people's tolerances. But you can't become a Senior without being a Junior first, so sorry, you were just the one to give him some experience. :)

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?

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.

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.

In this case the author describes a jerk who's more effective than the rest of the team combined. In this case, I kind of wonder whether it was a mistake hiring such a team.

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.

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.

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

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.

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.

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.

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,

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

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.

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.

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

:-D

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.

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

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.

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

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

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.

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.

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.

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.

http://www.slideshare.net/reed2001/culture-1798664/35-Brilli...

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

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?

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?

https://mikeseablog.wordpress.com/2015/02/26/the-hero-anti-p...

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

    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.

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.

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

Was Richard Feynman a jerk?

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.

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.