Live data from Hacker News

Brilliant Jerks Cost More Than They Are Worth

retrospective.co

251–260 of 279 posts

Re: Brilliant Jerks Cost More Than They Are Worth

#251

Earlier quoted context omitted.

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

An interesting analogy is the tradeoffs in going from one machine to a distributed system: a single SQL server will outperform a 3 node cluster for small loads, but the 3 node cluster will survive hardware failures and eventually out-scale the single-node setup as you add more nodes. It feels like larger companies are always reluctant to have a single point of failure, whether it's a machine in Utah going down or Gre…

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

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

Re: Brilliant Jerks Cost More Than They Are Worth

#252
post #217
post #191

Earlier quoted context omitted.

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 th…

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…

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.

Re: Brilliant Jerks Cost More Than They Are Worth

#253
post #233
post #228

Earlier quoted context omitted.

Did you have a typo? Or did you mean to only loop ten million times in the first case and 100 million in the second?

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

Am I reading that right: on average it's 10x faster to use a float literal?

Re: Brilliant Jerks Cost More Than They Are Worth

#254
post #25

Earlier quoted context omitted.

> Brilliant jerks are often to be found at the beating heart of successful software. Exhibit 0: Linus Torvalds

Exhibit B: Steve Ballmer.

Not brilliant. He was simply in the right place at the right time.

Re: Brilliant Jerks Cost More Than They Are Worth

#255
post #13

> 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 ar…

Hey that's me! I had a frustrating moment the other day where a colleague said that float(5) was more explicit and personally preferred in Python than a literal 5.0 I realised I was being pedantic but I genuinely believed in "good craftsmanship" when I really pushed him to change it. I need to get better at this because the social friction I caused may cost more than the poor craftsmanship. But the other part of me i…

They're still both magic numbers.

Re: Brilliant Jerks Cost More Than They Are Worth

#256

Earlier quoted context omitted.

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 ", or (best), "I don't understand why this is recommended, where can I learn more" (which hopefully doesn't end up on a holistic le…

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. FWIW, I'm firmly on the 5.0 side.

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.

Re: Brilliant Jerks Cost More Than They Are Worth

#258
post #21
post #14

No they don't; mediocre 'nice guys' do though. Every 'brilliant jerk' I've worked with and led has been a net positive over the long haul. Every mediocre nice guy has been dead weight that costs everyone around them time. I'll take the brilliant jerk any day. They can simply deliver in ways that others cannot.

> I'll take the brilliant jerk [over the mediocre nice guy] any day. Holy false dichotomy, Batman. I'd rather take neither of them and fill my team with adequate-to-exceptional devs who also happen to be decent human beings.

If you believe that niceness (the opposite of a jerk?) and brilliance are independently varying traits, and that each are sought after in the market, then you might suspect that eventually those who have the greatest number of independently varying good traits will be more likely to be sniped up by discerning firms than not.

In which case, based on your budget, you'll have to settle with fewer and fewer desirable traits of lesser magnitude, or conversely, based on your budget, you can push more and more less desirable humans to lesser firms; one can imagine thinking the same with customers or clients as well.

You can have the nice paying client, or the jerk paying client, and a discerning firm might prefer nice paying clients over jerk paying clients (but of course, the most important discernment will be over pay), leading their competitors to have to deal with clients with a smaller set of desirable traits.

Re: Brilliant Jerks Cost More Than They Are Worth

#259
post #28

Earlier quoted context omitted.

I agree... usually when a truly brilliant developer is causing more harm than good, it's because they aren't being effectively managed. That doesn't mean managing them is easy, but you want to pick and choose what problems you give them, who they work with, and how they work with customers. Of course, that's not my job :^)

Usually? The overlap in the Venn diagram between "Truly brilliant developer" and "giant baby who has no social skills" is probably non zero, but I work with many brilliant non-jerks. Perhaps you've been unlucky.

As opposed to intelligence and sociability, among other traits, may be independently varying?

If one imagines that intelligence and sociability are merely two of many possible desirable traits, and that top firms with big budgets also see similarly, then eventually those with the highest concentration of desirable traits will be sniped up, leaving firms with lesser budgets to take those with fewer desirable traits of lesser magnitude.

The same can be said about customers. Some customers could be described as "10x paying nice customers", vs "10x paying jerk customers", and these could be thought of as merely two of many possible independently varying traits. Eventually, one might suspect that discerning firms will try to keep the best clients, while pushing clients with fewer desirable traits of lesser magnitudes to lesser firms.

Re: Brilliant Jerks Cost More Than They Are Worth

#260

Lots of thoughts around the code review issue (the jerk generated 'hundreds of comment'). I have a rule: the only comments I make are about improving the correctness of the code. Nothing about technique or approach or format or cleverer ways of doing anything. Just directly actionable constructive comments.

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

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

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

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

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

Post reply on HN