> A “No Jerks” Policy Must Be Built Into Your Culture. It is entirely possible to be extremely passionate (and even brilliant) without being a jerk. A “no jerks” policy must be preached and practiced from the highest levels.
Following simplistic rules like this is usually what leaves us knee deep in the proverbial.
Maybe I've been lucky, but I've never worked with anyone who's as much of a jerk as described in the article. In my experience, talented developers are usually intelligent enough that they can make up for their shortcoming in the social area by consciously adapting their behaviour. They're not "normal" but they function well enough to work with others.
I've worked with plenty of jerk-ish, abrasive, opiniated, "take no prisoners" people who can be very fiery in meetings and can be highly critical of other people's work. Yes, they can be a giant pain in the arse - they're just so damn challenging. But in my experience they're normally challenging because they want the company to do better.
But I've seen many times (mainly in large companies) teams that were populated and led by people who were very consensus-based, had superb social skills, and had a genuine drive to succeed - but didn't because there was not enough fire in the team to make the right choices.
To me, the business of software development is way too complex to apply a simple "no jerks" policy. Brilliant jerks are often to be found at the beating heart of successful software.
I'd rather have a brilliant jerk than a regular jerk.
But regular jerks abound at work because they at least don't make you feel stupid and insulted.
And you hit the nail on the head with your experiences. In high school I was neck-and-neck academically with a brilliant jerk. He went to Harvard, is now a millionaire (without inheriting it) and a much nicer person. Competing with him was one of the most formative periods of my life. He made me better, because I learned not to take harsh criticism and hectoring so seriously. Look at what they do (for you), not what they say (to you).
I actually wish there were a brilliant jerk like him in my workplace. But there are just regular jerks.
> In my experience, talented developers are usually intelligent enough that they can make up for their shortcoming in the social area by consciously adapting their behaviour.
That's orthogonal to the issue mentioned in the article. For the purposes of "not being a jerk", it doesn't matter if that comes naturally or if you have to devote conscious effort to it; only the resulting behavior matters.
> Brilliant jerks are often to be found at the beating heart of successful software.
Survivorship bias. Strange policies or properties are often found in successful companies/projects, who often write up articles about them as though those policies contributed to their success, never considering the possibility that they succeeded in spite of them. The same goes for jerks: some companies/projects succeed in spite of the jerks in (or running) them.
OTOH, you can make a pretty strong argument that for, say, MS, Oracle, or Apple, it's precisely the 'jerk-y' qualities of their founders and CEOs that led to their success today.
Say what you like about MS's business practices during the 90s, but I think the history shows that a large reason they were able to continue their dominance was because of the unfair and frankly anticompetitive practices that they embraced back then. Bill Gate's willingness to be a jerk was what kept their company on top.
Of course, that was directed productively and outward, not destructively inward.
> I think the history shows that a large reason they were able to continue their dominance was because of the unfair and frankly anticompetitive practices that they embraced back then
While there might be a correlation, I don't think you can entirely extrapolate between "ruthless business practices" and "toxic interpersonal interactions". You can have either without the other, and I wouldn't automatically assume that skill at one implies skill at the other.
Context is everything. Profanity and hyperbole are as far from the aloof and stuffy professional language one uses with unfamiliar people or those in higher positions. It's something that becomes appropriate in personally close and comfortable quarters, and it can be a signal of comradery.
fwiw that kind of phrase isn't necessarily 'jerky.' As long as the person you are saying it to understands that you respect him/her, and are just disagreeing with their idea, then it can be fine.
It's a risky communication strategy, but I wouldn't condemn everyone who uses it.
> As long as the person you are saying it to understands that you respect him/her
what kind of person would say that with full vitriolic sincerity to someone they respect? Why say that when you could say, "I strongly disagree for the following reasons..." or something else similarly diplomatic and actually productive?
Oh right, and I forgot Marc Andreesen. This was from The Hard Thing About Hard Things:
To: Marc Andreessen
Cc: Mike Homer
From: Ben Horowitz
Subject : Launch
I guess we’re not going to wait until the 5th to launch the strategy.
— Ben
To: Ben Horowitz
Cc: Mike Homer, Jim Barksdale (CEO), Jim Clark (Chairman)
From: Marc Andreessen
Subject: Re: Launch
Apparently you do not understand how serious the situation is.We are getting killed killed killed out there. Our current product is radically worse than the competition. We’ve had nothing to say for months. As a result, we’ve lost over $3B in market capitalization. We are now in danger of losing the entire company and it’s all server product management’s fault.
Most people can see through "I strongly disagree for the following reasons..." as a euphemism for "your idea is stupid, and this is why..." And the more you emphasize "strongly" in the former, the more likely "fucking" materializes between "is" and "stupid" in the latter.
That kind of bland vocabulary makes one's statements sound like limp static. Corporate dialect is contrived to remove strong (corporate-environment-inappropriate) emotion from your speech. If you're well acquainted with your colleagues, then I'd hope you could express yourself more genuinely. You're probably more relatable than a peppy talking head who never offends anyone.
In this cases, shouldn't the discussion be purely about the technical merits of the idea, rather than emotions of the people speaking about it? I would count removing unneeded emotions from the conversation as a positive thing.
I'm a machine learning engineer so "unneeded input" is something I rarely consider as a valid statement. Oftentimes when you're arguing the merits of one approach versus a different one, you have to use your rhetorical skills to influence another party. You both believe you have the best solution. You believe your logic is consistent and complete.
Emotion is a very powerful signal during discussion. It's a counterpoint to logic; they work together. Rarely does logic by itself win anyone over. Trying to remove "unneeded" (who decides what an unneeded emotion is) emotion is folly. We're not Vulcans.
So, all things being equal and arguments having the same merit, the less polite and less rational person wins. If i am able to contain emotions and argue by facts only, I will be at disadvantage.
Diplomacy is not always necessary to get productivity.
Tip-toeing around the issue can make things much worse.
It is much easier to say, "Stop. That's stupid, try again."
Than to try and cherrypick what they've done right, because often times, there isn't anything useful there.
Considering that Gates, Jobs, and Torvalds all have stories where they tell someone what they're doing is stupid, and actually get a decent product out at the end of the day, it doesn't seem like diplomacy is necessary at all.
If you can't say ~why~ it's "stupid," your comment is not useful. And if you do say why it's stupid, those reasons are much more important than the inflammatory adjective "stupid," so just say those instead.
It's hard to feel respected when you're constantly hearing all about how "fucking stupid" your ideas are. I know in theory you're supposed to separate criticism of your ideas from criticism of you, but in reality that isn't always easy when the statements being made are so strong.
Yeah, it's a risky strategy. I recently interviewed with a company that had "thick skin" as one of their hiring criteria, and told candidates that they insulted each other, and someone getting hired couldn't take things to seriously.
I'm willing to bet that there is a correlation, to some extent, of level of jerkiness one can tolerate and income. The more jerk you can tolerate, in many types of companies, the higher you can move up. (to a certain extent, above a certain threshold; and the correlation is probably stronger among larger companies.) Mostly due to shifting upwards and towards the business side of things; management, strategy/biz development, or what have you.
For example, the person who wrote this article, is less of a fit for a cutthroat, decisive, business-minded management position; and might maximize their relative potential (in their current situation and state) by reaching a level that's below any business-minded interactions.(captain of a development team, answers to a manager who isolates them from business/mean/jerkish discussions.)
Having worked at a company with very nice people and no fire to actually get things done (just platitudes), it can be just as bad of an environment if your goal is to succeed. Often times people come in to "play work" and achieve only a fraction of what's possible.
Fire and courtesy are hardly incompatible. But it's more than twice as hard to achieve both as to manage one or the other.
It's also a question of circumstance. Right now, for example, I'm working to mitigate, and eventually to resolve, a morale crisis on my team, which exists for good and cogent reasons that don't merit discussion here. Now is not the time for fire - and fire alone in any case works only when the vision is so powerful that smart, capable people will tolerate being driven painfully hard to achieve it. Without offering something to make that worthwhile, fire can't drive them onward - it can only drive them away.
Fire is not always the solution to any problem of course, but a lack of being results driven can make for large morale problems in itself - especially in engineering where you can keep working on one insignificant detail or another in perpetuity. I've spent months constantly asking for business goals to be set so we can meet them and being told to hang tight. I've left those companies because the environment becomes quite toxic over time, with the "true believers" believing that everything is going swimmingly because they don't have any pressure put on them, and the ones looking to accomplish things spinning their wheels fiercely in the mud.
In any case, I'm not trying to argue with you, and I hope I don't come across as if I were. It's just that I feel like there's a strong reaction in this thread to a bias, whether perceived or actual, on the part of the article author and in the direction of courtesy. So my purpose here is to sound a cautionary note, and attempt to keep visible in the discussion what I regard to be the nuance of the matter.
Especially since a lot of engineers default to brusqueness, which I totally understand while finding often counterproductive. It can work in a collegial setting, among secure peers who share mutual respect, but in any other context it just looks like asshole behavior - and that is exactly what it is.
To understand one's audience, and adjust one's persuasive style to suit, is a fundamental aspect of rhetoric, and given the ubiquity of office politics and the necessity thereof - a topic meriting its own essay, which I will not write on a phone - such understanding and adjustment is important to professional success, as well. I think that's something it is easy for us to overlook, because computers only need to be told and then sworn at, not persuaded.
Also, all else equal, it's both more ethically sound and more useful not to act like an asshole. Leaving a trail of hurt feelings behind you is no way to go through life. Sure, we might excuse it in someone with a vision on par with that of Steve Jobs. But no one here is on par with Steve Jobs.
In more ways than one. When jerks are allowed to be jerks, people who do not want to deal with jerks leave the company. So the jerks bubble up to the top, while otherwise great engineers who don't want to be berated move along to better things.
Exactly. You have to pick: either the jerks, or the people who the jerks drive away. And that doesn't take into account the people who aren't quite driven away but find work that much more unpleasant as a result.
If you encounter many skilled jerks, consider why that might be, and why in the same environment you don't also encounter skilled people who are fun to work with. In such an environment, the skilled people who are fun to work with can afford to leave, while some of the non-skilled people may not have that option. So, it's natural that within such an environment (company, project, etc), it'll look like a correlation between jerkiness and skill. People then start assuming a causation, and thus contribute to that same cycle.
The opposite environment, with many skilled people who are fun to work with, will tend to reject jerks regardless of skill. I've also noticed that such an environment tends to have a much higher degree of mentorship and collaboration, in addition to being more fun to work in, and boosting energy rather than draining it.
Entirely possible. But the viewer may also just be in an environment with skilled jerks that have driven off skilled non-jerks. So whether the viewer is a jerk, nice, or indifferent won't necessarily change the apparent correlation they observe around them between jerkiness and skill. The danger lies in generalizing that observation and assuming it applies outside that environment.
> Brilliant jerks are often to be found at the beating heart of successful software.
Survivorship bias doesn't render this an ineffective argument against the simple "no jerks" policy argued for in the article.
The contention is "(jerk present) → ¬ (success)", aka "¬ (jerk present) ∨ ¬ (success)". A single case of "(jerk present) ∧ (success)" is sufficient to disprove the direct implication.
> The contention is "(jerk present) → ¬ (success)"
The contention in the article is not "you can't ever succeed if you have a jerk on the team" or "a jerk will always cause your team to fail". A property doesn't have to be universal to be common enough to be worth writing about.
So no, a single instance of succeeding despite a jerk does not "disprove" anything relevant here.
> To me, the business of software development is way too complex to apply a simple "no jerks" policy. Brilliant jerks are often to be found at the beating heart of successful software.
That's what you replied to with "but survivorship bias!". And the article itself says:
> A “no jerks” policy must be preached and practiced from the highest levels.
... which is a universal and normative call to action.
English isn't formal logic, and treating it as such creates a strawman. An article recommending a "no jerks" policy is not a formal theorem that "jerks universally lead to failure", nor can it be refuted and dismissed by an anecdote of "but we had jerks and didn't fail".
If jerks universally led to failure, it would hardly need writing about more than once, as everyone would very quickly have to understand and deal with it. However, because you can sometime succeed in spite of the presence of jerks, that makes it a problem particularly worth writing about.
I agree... usually when a truly brilliant developer is causing more harm than good, it's because they aren't being effectively managed. That doesn't mean managing them is easy, but you want to pick and choose what problems you give them, who they work with, and how they work with customers. Of course, that's not my job :^)
And the big win is that it's quite possible to go from "asshole" to "amicable." It's less likely someone goes from "mediocre" to "brilliant." A good manager can go a long way in coaching you professionally, but they can't raise your IQ.
Usually? The overlap in the Venn diagram between "Truly brilliant developer" and "giant baby who has no social skills" is probably non zero, but I work with many brilliant non-jerks. Perhaps you've been unlucky.
As opposed to intelligence and sociability, among other traits, may be independently varying?
If one imagines that intelligence and sociability are merely two of many possible desirable traits, and that top firms with big budgets also see similarly, then eventually those with the highest concentration of desirable traits will be sniped up, leaving firms with lesser budgets to take those with fewer desirable traits of lesser magnitude.
The same can be said about customers. Some customers could be described as "10x paying nice customers", vs "10x paying jerk customers", and these could be thought of as merely two of many possible independently varying traits. Eventually, one might suspect that discerning firms will try to keep the best clients, while pushing clients with fewer desirable traits of lesser magnitudes to lesser firms.
He may flame on mailing lists from time to time, but I prefer an honest character to CoC thumping Machiavellis who talk and behave like politburo members.
The latter actually harm and exclude people while acting politely; Linus does not.
I have near unlimited respect for Linus. He has an allergy to bullshit. He does not mince words when preventing any kind bad code or needless complexity from entering the kernel.
The same things that make some people consider him an "asshole" are the same things that make him so effective.
I'm really not convinced that Linux is successful because of Linus's jerk-ness.
I think it's successful because the BSDs were under a cloud of legal suspicion in the early '90s (the USL lawsuits) and Mach didn't have zero-copy message passing, and so as a result, Linux was basically the only free software general-purpose UNIX-alike for 386s that existed. (MINIX resisted being general-purpose until 2005.)
Once you have that, it's basically a matter of network effects.
There are a ton of things Linus did right, of course. There are also a ton of ways he could have destroyed the project, but didn't. All of those are praiseworthy. But we have exactly one data point, and I don't think we can extrapolate a rule from that, certainly not a rule that everything he did was right. If there had been Linux and 386BSD competing on equal terms, who knows what would have happened.
Brilliant jerks are, in fact, often to be found at the beating heart of successful software. That is true. But would that software have a different beating heart if not for them? Would it be more successful?
Jerks and non-jerks have different approaches to building enterprises. Jerks often rule through intimidation and fear. Non-jerks build loyalty through other mechanisms.
The thing is both methods, if applied consistently, produce results. The trouble is the jerk method is a lot less efficient in terms of use of human emotional capital.
I 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?"
I have found that it's best to leave coding discussions like that to tools - we use Rubocop and Overcommit and it's a huge PITA every time it points out a minor quibble (we stop commits locally on our machines if new code doesn't pass both) BUT it saves us from having those conversations during code reviews. My general rule of thumb is that if there is a question of style that isn't caught by Rubocop, then it's very likely not worth having.
The other upside is that code reviews are higher quality and design focused.
It used to, but it doesn't anymore, presuming you use a reasonably recent compiler. If you enable optimizations the assembly for that snippet and the default constructor are identical, I last checked on some GCC 5 flavor, but I think it was like this all the way back in GCC 3 something.
Compilers can do some pretty fancy things with literals because they know they optimize constants known at compile time.
I just started using GCC 5.4 - I'll have to check again. Last I checked was around 4.8, and it was still generating sub optimal code with the empty literal.
This one's tricky, because you're absolutely right, and telling them that won't help them improve. Try asking them, "hey I must have not read that PEP, can you link me to where that's recommended so I can get in sync?", or "hey I read this guide recently and it recommends doing X because <actual legitimate reasons>", or (best), "I don't understand why this is recommended, where can I learn more" (which hopefully doesn't end up on a holistic learn-the-world journey that ends with a 1-to-1 with your boss where you share your concerns about this developer's performance).
"Good craftsmanship" is both subjective AND hard to relate to an increase business value. Better to stick with third-party recommendations, like textbooks or linters.
Why appeal to authority here? Experienced, well-intentioned developers should able to have a discussion of the merits of a particular construct without having to turn the discussion into a citation count contest.
Ohhh boy. The problem is when the guy on the float(5) side genuinely believes that this is better code style. At the end of the day you do have to appeal to some system, whether it be to the PEP, or to SOLID design principles, or even to "someone else thinks this is a good idea on stack overflow".
Personally I like to go with "is accepted by the community" as opposed to "is accepted by most people in this room" or "Greg thinks it's beautiful".
It's not appeal to authority, it's consider the point of view of a disinterested third-party that they may not be aware of and thus can gracefully accept your feedback without losing face.
We all have that part. The trick is not to let it make you an asshole. There might be times when that's the right thing to be - satisfying a pedantic quibble over a style preference, to the detriment of morale and team cohesion, is never, ever one of them.
I've found the first few chapters of _Crucial Conversations_ extremely useful.
Manager-Tools.com speaks very well to relationships being very valuable, worth more than float(5) vs 5.0... though... I really do agree. Float(5)? Really? And 5 should be replaced with IntNoReallyItJustAnInt(5)?? ;)
Unless you can prove that one method is significantly faster or the other structurally dangerous, it is just a matter of coding style and opinion. Agree to disagree, or let the lint tool be the referee.
I did the lazy approach and let timeit pick the count. Specifying the number of loops doesn't change the result:
$ python -m timeit -n 10000000 'float(5)'
10000000 loops, best of 3: 0.0771 usec per loop
$ python -m timeit -n 10000000 '5.0'
10000000 loops, best of 3: 0.00717 usec per loop
[timeit] provides a simple way to time small bits of Python code. It has both a Command-Line Interface as well as a callable one. It avoids a number of common traps for measuring execution times. See also Tim Peters’ introduction to the “Algorithms” chapter in the Python Cookbook, published by O’Reilly.
Yes. The difference is the Python compiler is not optimizing out the float() conversion, so every time it creates the value 5.0 it is calling the float() conversion on the literal "5".
Different machine, so the timings are different from above, but here are some permutations:
Float literal:
$ python -m timeit '5.0'
100000000 loops, best of 3: 0.0152 usec per loop
Integer literal coerced to a float:
$ python -m timeit 'float(5)'
10000000 loops, best of 3: 0.146 usec per loop
Float literal coerced to a float:
$ python -m timeit 'float(5.0)'
10000000 loops, best of 3: 0.143 usec per loop
Integer literal:
$ python -m timeit '5'
100000000 loops, best of 3: 0.0152 usec per loop
Float literal coerced to an integer:
$ python -m timeit 'int(5.0)'
10000000 loops, best of 3: 0.155 usec per loop
Integer literal coerced to an integer:
$ python -m timeit 'int(5)'
10000000 loops, best of 3: 0.14 usec per loop
Very cool thanks. So something like PyPy would probably very quickly optimize it, since it has a deterministic result. I think I'm going to experiment with that one.
Isnt this a very python thing. Arent all the "brillant jerks" python and ruby programmers. Java and C/C++ guys are the actually smart dudes that know what they are doing and PHP guys just want to get it working and dont give a fuck.
I can't imagine any smart developers using Ruby anyone, I know because I unfortunately work with Rails and anyone with a brain cell has already left. To me deciding to use Rails isn't a very smart decision
I tell myself I can work with (almost) anyone who is trying to do better. If someone is intentionally being subversive, that's hard to work with. Humans are difficult, and the people that own that & try anyway are my kind of people.
Every organization needs a rogue here and there - one who will challenge conventional wisdom and authority in confrontational, i.e. jerkish, ways. It's management's job to try to fit them in and put them in the right positions. I'm sympathetic because I'm very socially inept myself.
I think it's possible to be truthful, direct and blunt while still being nice and thoughtful. There's a false association between someone who is a jerk and someone who is willing to disagree.
> I've never worked with anyone who's as much of a jerk as described in the article
Maybe it's just that jerks don't affect you as much as they do other people. And that's great- for you. But for the rest of the team around you, those people are awful. Those people are the reason your best teammates decide to move on to new opportunities.
You should also consider the old saying 'every team has an idiot, and if you don't know who the idiot is, it's you', and double check that this doesn't also apply to jerks. Maybe the reason you haven't worked with a jerk before (and in fact believe brilliant jerks are just the best) is because you are the jerk.
I don't mean to say that as an insult. I was the jerk. I still am the jerk sometimes. It's hard to see, hard to deal with. Maybe you aren't, but it's worth careful examination just in case, no? Otherwise, you're literally making people around you miserable.
> Those people are the reason your best teammates decide to move on to new opportunities.
Are they? Most devs I know change jobs to work on more interesting projects, to move into a higher level role, to get a pay bump, to move to a more flexible company, etc.
In my experience it is rare for someone to move because of bad colleagues. Bad management? Sure. Bad co-workers? Not really.
Why do you work at companies with so many jerks? Perhaps you are the problem.
Maybe I'm the exception, but I have worked with someone as bad as the article described. He would re-write everyones code when they weren't around, because he didn't consider it good enough, so they were completely de-moralized. Eventually he was assigned solo projects, which became overly complex and were never finished, until he left the company. Management should have noticed earlier how unproductive he was to have around.
That doesn't sound so much like a brilliant jerk as a midwit egomaniac, which are pretty common on the ground in programming. I've worked with people like that too, and what they're really doing under the guise of making your code better is rewriting modules because it's less trouble than figuring out how the existing code works. Invariably they break something in the rewrite, too, because they didn't understand the full scope of the problem domain (which, circling back, is why they didn't understand the original code).
And of course when you assign them to solo projects they fail. Because they're not very good at software development.
Success can be determined by many different things; but pretty universally in programming not getting the job done correctly (the expected inputs and outputs just aren't there) is an issue.
Which confirms your interpretation and labeling of the 'midwit egomaniac'.
The sad part - it is not usually immediately clear which kind of jerk your dealing with, since they behave the same!
Secondarily, it is not immediately clear to an outsider upon observation which is which either...
Summary I drew: There are genuine mental health related conditions that can cause someone to be a jerk AND still be brilliant. When you find that, you have to first separate them off so as not to detract from others work. Secondly if they can't cut it then let them go.
That's very well put. The "mid-wit egomaniac" is much more destructive than the "brilliant jerk." The jerk at least knows that rewriting working code is expensive and risky.
That's probably pretty accurate. He was really brilliant, and had extremely broad technical knowledge, but he was not as brilliant has he believed himself to be. Since his code was difficult for anyone else to follow, and as mentioned earlier, everything was over-engineered out of existence.
I belive that "no jerks" policy basically means that everybody needs to be nice and civil with each other.
This does not mean that mistakes are allowed and things are done by consensus.
The problem with jerks is that they are jerks: people do not like them and it is hard to work with them and that is not good. Nothing else. Sometimes that is ok - but in many cases it is not ok since team and project needs to grow into other areas where that "brilliant jerk" will not be so brilliant.
The problem is that the meaning of "civility" is mutable. Too often, "being civil" or "being nice" or "being respectful" ends up meaning going along with the flow and not challenging the group consensus.
I stopped reading when the blogger started talking about the "brilliant developer who could code circles around us", and then referred to him as a "10x developer".
These are stereotypes, and quite often bloggers will make up stories to illustrate a point. Which is fine, but when your point is based upon stereotypes, then I'm not interested.
----
So with that said, I agree with everything you've said. Quite often these abrasive people are making valid points.
You know those security scandals that hit (Playstation network getting hacked, etc) where you think to yourself "how the fuck did they manage it so badly, because their fuckup wasn't subtle at all.
You KNOW there was an abrasive jerk somewhere in there saying "guys... this is horrible" and he or she got shouted down, shutdown, and/or fired for it.
Or there was an abrasive jerk who made them to do the wrong thing. Abrasive jerk was likely to be the one doing then shouting down. Abrasiveness does not make you right, the assumption that the most pushy jerk is right is just wrong.
We should be putting "abrasive jerk" in quotes. The point that was being made by both of us is that these abrasive jerks aren't actually abrasive jerks, they're just going against the grain because it's the technically better choice.
And then they get labelled as abrasive jerks and ignored, and then queue the scandal when people talk about how horrible the toyota code is (for example).
How do you know the jerk is jerking for the technically better choice? You don't. These debate always assume that the person who is doing criticism is right. That is not the case in real life. Criticism can be both right and wrong.
Note that these people did not really bought into his theories and opinions nor were able to follow his instructions - the amount of code review complains would go down it that would be the case. He did not managed to change the culture toward good nor to teach them. His reach was limited by what he was able to micromanage at the moment.
No, you're right, I'm sure that somehow Sony managed to hire an entire team of sys admins that were so incompetent that none of them actually realized just how vulnerable their system was.
like... every. single. one. of their sys admin team was really that oblivious. Out of all the people they hired, not even one competent got accidentally picked up somewhere along the way, during all the years they were were running that network before it happened.
Or maybe, their sys admin team was acutely aware, but management didn't give them the autonomy to choose to fix it, and anyone who spoke up and tried to push for the issues to be fixed got labelled as "not being a team player", or a "troublemaker", or even ... gasp ... an "abrasive jerk".
And then they got booted, and everyone else learned the lesson and just shut up and kept collecting the paycheck.
And then suddenly they get hacked, and then finally management was willing to spend the money on securing things better.
1.) It is perfectly possible to have bad hiring process. That might not be just management fault, technical skills needs to be checked by the technical team. Abrasive jerks in it will select for conformity with their opinions instead of knowledge.
2.) It is perfectly possible that abrasive jerks were the ones who prevented others to fix the problems. In particular, they could have created a culture where new employee or junior is not expected to accept all criticism but is shut down when he dish it out.
"This is stupid" is not exactly an argument - if that works then your tech seniors are preferring conformity with jerk over merit of argument. It works somewhat when all working with him are juniors (e.g. less likely to see bigger problems), but makes you impenetrable to valid criticism from other skilled people.
3.) You assume that the problem was lack of autonomy from the management. That is possible, but it is equally possible that tech team screwed up on their own. Organizing larger teams is hard and even super skilled techies, abrasive or not, may completely fail once the group is too big to be micromanaged.
---------------------------------------------
Being abrasive and being direct/open is just not the same. Abrasiveness makes people comply, because they do not want to be humiliated by you. Abrasive people are just expecting everyone to be conforming to whatever they think, they do not create an environment where bad processes get fixed. It does not make people agree with you and they will revert back to the original behavior the moment you don't see.
I think abrasive people tend to be very contrarian. And when large companies like Sony make terribly boneheaded decisions it's not because every individual simultaneously made the same stupid decision. It's because everyone was drinking the cool-aid. And abrasive people are generally far less likely to drink the cool-aid. So I think when a a large company makes a boneheaded decision the people arguing against that decision are more likely to be more abrasive than general populace.
That, or they had a reputation for "moving fast and breaking things" without submitting to any secure practices, and the abrasive jerk who knows security never bothered to apply there in the first place. Or the polite person who knows security, for that matter.
Please don't. Our industry is already full enough of assholes who saw part of the Steve Jobs movie and started to think that management is all about berating or "negging" people so they do what you want.
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.