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.

Emotion is a very powerful signal during discussion. It's a counterpoint to logic; they work together. Rarely does logic by itself win anyone over. Trying to remove "unneeded" (who decides what an unneeded emotion is) emotion is folly. We're not Vulcans.

That is not meritocracy and pretty bad workplace.

Tip-toeing around the issue can make things much worse.

It is much easier to say, "Stop. That's stupid, try again."

Than to try and cherrypick what they've done right, because often times, there isn't anything useful there.

Considering that Gates, Jobs, and Torvalds all have stories where they tell someone what they're doing is stupid, and actually get a decent product out at the end of the day, it doesn't seem like diplomacy is necessary at all.

If you can't say ~why~ it's "stupid," your comment is not useful. And if you do say why it's stupid, those reasons are much more important than the inflammatory adjective "stupid," so just say those instead.

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.

I think it's successful because the BSDs were under a cloud of legal suspicion in the early '90s (the USL lawsuits) and Mach didn't have zero-copy message passing, and so as a result, Linux was basically the only free software general-purpose UNIX-alike for 386s that existed. (MINIX resisted being general-purpose until 2005.)

Once you have that, it's basically a matter of network effects.

There are a ton of things Linus did right, of course. There are also a ton of ways he could have destroyed the project, but didn't. All of those are praiseworthy. But we have exactly one data point, and I don't think we can extrapolate a rule from that, certainly not a rule that everything he did was right. If there had been Linux and 386BSD competing on equal terms, who knows what would have happened.

Brilliant jerks are, in fact, often to be found at the beating heart of successful software. That is true. But would that software have a different beating heart if not for them? Would it be more successful?

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.

http://thehustle.co/steve-job-insults

http://www.forbes.com/sites/davidcoursey/2011/10/12/steve-jo...

http://bgr.com/2015/06/18/what-its-like-to-work-for-steve-jo...

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.