Brilliant Jerks Cost More Than They Are Worth(retrospective.co)
retrospective.co
Brilliant Jerks Cost More Than They Are Worth
https://retrospective.co/brilliant-jerks-cost-more-than-they-are-worth/
278 comments
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.
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.
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.
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.
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 was directed inward, too. "That's the dumbest fucking idea I've ever heard," was a common phrase at MS in the 90s.
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.
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?
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:
— Ben
Next time do the fucking interview yourself.
Fuck you,
Marc
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: LaunchNext time do the fucking interview yourself.
Fuck you,
Marc
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.
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.
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.
That is not meritocracy and pretty bad workplace.
That is not meritocracy and pretty bad workplace.
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.
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.
> "Stop. That's stupid, try again."
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.
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.
>"That's the dumbest fucking idea I've ever heard,"
How ironic.
How ironic.
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.)
Edit:grammar
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
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.
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.
Oh, to be sure. Neither alone long suffices.
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 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.
You found the perfect words for how I currently feel.
> Survivorship bias.
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.
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.
See also https://www.youtube.com/watch?v=-ZSli7QW4rg and http://www.slideshare.net/dberkholz/assholes-are-killing-you... .
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... .
> If you encounter many skilled jerks, consider why that might be
Often that might be because the viewer is unaware of their own jerkness, and only sees others reciprocating.
Often that might be because the viewer is unaware of their own jerkness, and only sees others reciprocating.
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.
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.
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.
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.
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.
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.
> Brilliant jerks are often to be found at the beating heart of successful software.
Exhibit 0: Linus Torvalds
Exhibit 0: Linus Torvalds
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.
The latter actually harm and exclude people while acting politely; Linus does not.
Completely agree.
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 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.
To be fair, Linus is like the last line of defence for Linux. If being a jerk helps remind the strict rules that he envisioned, maybe it's working.
Ah, the tiger-repelling rock hypothesis: https://www.youtube.com/watch?v=fm2W0sq9ddU
Other people are saying he could be softer and I don't disagree.
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?
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?
[deleted]
Exhibit B: Steve Ballmer.
There are multiple ways to be a jerk. Clearly Gates succeeded and Ballmer failed. The Gates went on to stop being a jerk.
It would be nice to see some example of a Jerk and non-Jerk attempting the same strategy.
It would be nice to see some example of a Jerk and non-Jerk attempting the same strategy.
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.
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.
Not brilliant. He was simply in the right place at the right time.
The article is in the context of a business, not an OSS project. It's apples to oranges.
Hey that's me!
I had a frustrating moment the other day where a colleague said that
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 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?"
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.
The other upside is that code reviews are higher quality and design focused.
By the way, float(5) is slower, because it creates two objects instead of one.
I pointed that out but also immediately conceded they it doesn't matter since it was instantiated once at runtime.
Which is why I call it craftsmanship. It works the same for all intents and purposes, but c'mon. :)
Which is why I call it craftsmanship. It works the same for all intents and purposes, but c'mon. :)
One of my pet peeves in C++ is seeing:
std::string s = "";
It causes calls to strlen and potentially memory allocations. Just use the default constructor!
It causes calls to strlen and potentially memory allocations. Just use the default constructor!
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.
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.
Enabling the optimizations is important too. If you leave it on the defaults it does a very direct translation to machine code.
GCC 7 is available for use now.
GCC 7 is available for use now.
Absolutely agreed that the default constructor is better style, but won't it be optimized down to the same code anyways?
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.
"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.
FWIW, I'm firmly on the 5.0 side.
FWIW, I'm firmly on the 5.0 side.
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".
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.
Your colleague is clearly wrong. Seriously, 'coërce the integer five to floating point' vice 'the floating point number 5.0'?
Does he also prefer to right integers as 'int(float(5))'? The mind boggles, it really does.
Does he also prefer to right integers as 'int(float(5))'? The mind boggles, it really does.
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)?? ;)
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)?? ;)
You don't use Boolean.ToString(b).Equals("true") ?
It wouldn't even enter my mind to argue about something so trivial.
Then again, I'm not a software developer (even though I did write some Python scripts for my workflow in the past).
Then again, I'm not a software developer (even though I did write some Python scripts for my workflow in the past).
I'll be honest, it's pretty hard to see how it matters much either way.
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.
$ python -m timeit 'float(5)'
10000000 loops, best of 3: 0.0776 usec per loop
$ python -m timeit '5.0' 100000000 loops, best of 3: 0.00719 usec per loop
$ python -m timeit '5.0' 100000000 loops, best of 3: 0.00719 usec per loop
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. 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
$ 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
Am I reading that right: on average it's 10x faster to use a float literal?
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
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.
[deleted]
They're still both magic numbers.
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
What would you use? Serious question, I'm trying to figure this out.
Yeah, idiot GitHub programmers.
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.
If someone is intentionally being subversive, that's hard to work with.
Yeah, that's true. I'd rather work with an honest jerk than a friendly back-stabber.
Yeah, that's true. I'd rather work with an honest jerk than a friendly back-stabber.
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.
And to be sure, if they are talentless jerks, there's no reason to put up with them.
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.
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.
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.
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.
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.
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.
Exactly. Some of the most driven (and successful) people act like jerks. Steve Jobs is a noteworthy example:
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...
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...
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.
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.
Since it apparently wasn't obvious:
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).
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.
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.
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.
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.
[deleted]
Steve Jobs has been a well known jerk. It helped apple to have him.
Better to say he added value despite being a jerk; there are lots of companies that succeed without having egomaniacal bullies in senior management.
My first senior engineer was a "brilliant" jerk. He had decades of experience, but when I started digging into his work I realized that he was useful mainly because he was offering solutions to problems that he created. I've heard some people say that a good engineer will eliminate the need for his/her own job. This guy was actively creating a need for himself by causing problems without management realizing it.
About 1 out of every 10 ideas was a good idea, but you had to know how to filter out the bad ones. If you said "no" to one of his bad ideas, he'd say that you weren't listening to his input and complain to your manager.
He was abrasive, condescending, and dominated every meeting. If you said anything to management, their response was "Oh that's just Bob, what a crazy, quirky, eccentric guy!" What they refused to realize was that being Bob's peer was very different than working for Bob. What management perceived as a quirk, was a character flaw that made life hell for anyone working underneath Bob.
And to echo other comments, nothing was done about Bob because management didn't want to take responsibility for the culture of the company. Why risk negatively impacting profits by actually managing your employee when you could blame it on millennials being whiny and you believe that engineers are interchangeable?
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?
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 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.
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.
Nice false trichotomy there, Joker. I'd rather have brilliant developers who are also decent human beings.
I didn't say there's no middle ground. Of course I'd prefer the brilliant nice guy, but you don't always have that option.
I disagree on 'adequate' though. I'll take a truly brilliant a-hole over 'adequate'. 'Adequate' means I'm often fixing their mistakes, checking up on them, making sure they stay on track, etc. I'm ok with smoothing over issues from time to time if it means I can let them run wild on the thing I hired them for.
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.
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.
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 take neither of them and..
I'd rather drive a Ferarri.
I'd rather drive a Ferarri.
Are brilliant & nice people really as rare as y'all seem to be suggesting? That's not my experience at all.
If brilliant means not mediocre, or above average, they are as rare as they are common. Depends how your budget stretches; If it doesn't, you have to make do.
I tend to err on the side of EpicEng here. Those people are readily available and you're just not paying enough.
Truly brilliant people are extremely rare, so I'd say yes.
Same here. The so-called "jerks" are still just people and leadership is all about managing different personalities. I've yet to encounter a case where the even the most difficult person couldn't be handled properly. Any occasional issues are more than worth the productivity increases.
Not a chance. Brilliant jerks are a cancer on the team and business, and they very rarely deliver.
>and they very rarely deliver.
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?
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?
If your head count is 5 or less, one brillian jerk (BJ) can carry the team on his shoulders. If BJ's a 10x programmer, and the other option is to hire a brillian and nice (BN) who's merelly an 8x programmer, you are better off with the BJ as tech lead. Assume your core team was 5x, 4x and 2x before the hiring of the tech lead. The 4x and 2x guys will probably slow down BN to 6x, so you end up with 17x of team throughput. BJ, on the other hand will make 2x quit out of frustration, and 4x will be demoted to 2x because he will struggle to cope. 5x, on the other hand, is pushed beyond his zone of comfort and raises to 6x. Now you have a team throughput of 18x, but you will be paying one less (junior) salary.
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?
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?
>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.
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.
In my experience this type of person can only exist in your organization if their manager is below average. I have come across my share of them and every time if their manager was a dud the whole company suffered, if their manager was on the ball they would put structure around the jerk to achieve a net improvement in productivity without the negativity.
Steve Jobs, Bill Gates, Larry Elison and Jeff Bezos each nurtured that sort of person (and were themselves that sort of person). They utterly steamrolled the kinder and gentler companies in their respective markets.
Sometimes reality and what you want to be true are not the same.
Sometimes reality and what you want to be true are not the same.
Yes and no. There is brilliance and there is "being a jerk" and you can be brilliant and not a jerk and the organization will thrive, or you can be brilliant and a jerk and the organization will be better off without you.
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.
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.
Their personalities could not be more different. Their approach to business and life are completely orthogonal.
spot on, I have seen people like this who you wouldn't even call brilliant but excellent Prototype-Masters. usually they flourish because they can provide cover for some deep seated insecurity of their bosses (like knowing you are technically incompetent). the problem is that such people are credit suckers because their quick & dirty prototype can pass for the real thing in the eye of 'innocent bystanders'. Overall it just lowers morale of the team as nothing seems worthwhile anymore.
Thank god I dont work there anymore!
Thank god I dont work there anymore!
It's always possible the brilliant jerk is just being taken advantage of so his boss can take it easy. Exploiting ego isn't hard and you don't need to be better than him at his own game to do it. If his manager is insulated from the rest of you, it's probably not worth enduring the brilliant jerk though.
This has been my experience as well, if the manager does not stay on top of it the person is toxic. With sufficient incentives, they can be managed to lift up the team.
I've met two kinds of "brilliant jerks" in my working life. One is insufferable and makes the lives of his (it's usually a he) co-workers such a nightmare that they end up quitting. The other is abrasive but pushes his co-workers to achieve a higher level. I've even worked with one developer who was both and, while I hated every moment of working with him, I'm undoubtedly better at what I do now for having worked with him.
When I see opinion pieces like this, my first thought is always of the book "multipliers" which put forward (huge over-simplification) that you should strive to hire people who make their co-workers more productive. A jerk is often a strong individual contributor who detracts from the work of those around him. And to that extent, jerks should be avoided. But when a jerk is also a multiplier, they can drive achievement far greater than what would otherwise be achieved.
A good example of this is Steve Jobs who, by all accounts I've read, was a bit of a jerk, was abrasive and demanding, but also pushed his people to achieve amazing things, not just at Apple, but also Next and Pixar.
If you avoid the brilliant, jerky multipliers, you just might fail in the most enjoyable way possible.
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've met two kinds of "brilliant jerks" in my working life.
I think this is a key point, along with ianbicking's observation that jerkness is often an environmental (rather than innate) phenomenon. Here's a quote many here might recognize.
"Extremism in defense of liberty is no vice"
Substitute "quality" or "progress" for "liberty" and you might see what I'm getting at. Some people are just jerks, full stop, end of story. They won't stop being jerks. They will continue to bring everyone down, so they're best gotten rid of. However, there are others who can exhibit many of the same outward behaviors because of context. Most often, the context is that people aren't listening. In an organization where there's a strong emphasis on empirical results, and even more so in one where there's a strong focus on learning, this "situational jerkness" doesn't occur. On the other hand, when people persist in doing things that are wrong despite every prior proof that it's wrong, others might get frustrated enough with them to start being jerks. Examples from my own experience might include:
* Repeatedly deferring fixes to a known serious problem, while resources are devoted to less important things.
* Re-submitting the same proposal or patch without fixing already-identified flaws.
* Persisting in collaborative anti-patterns such as pulling rank or announcing decisions made without all stakeholders present.
I've been a jerk myself, when faced with these kinds of situations. I'd have to be some kind of jerk not to push for change, when experience tells me that the status quo leads to a bad place. Sometimes passive aggression needs to be met with active aggression. When faced with being a jerk for good or a jerk for evil, I'll choose being a jerk for good. It's not a decision to be made lightly, and if it happens often then we're probably back in "permanent jerk" territory, but sometimes it's a decision that needs to be made anyway.
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.
>One is insufferable and makes the lives of his (it's usually a he) co-workers such a nightmare that they end up quitting. The other is abrasive but pushes his co-workers to achieve a higher level.
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. :)
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. :)
I might describe them as a "selfless jerk" vs a "selfish jerk". A selfless jerk cares about the company and team, and while is abrasive is always doing it for the right reasons, and is trying to be effective for the company. A selfish jerk is just a jerk who cares about themselves.
I read articles like this somethings and think "holy shit I hope I'm not a jerk" - but then I relax when I realize I'm not brilliant enough for that to matter.
If you're conscientious enough to ask the question you don't have to worry about being a jerk :).
Well the real problem is if you are a jerk without being brilliant. ..
I think jerks come at all levels. I hope I'm not one either.
[deleted]
Well, let's look at it from the "the jerk"'s perspective.
How would feel if other people accomplished 1/10th what you did? What if they got paid 80% of what you got paid too?
What if teaching them took so much of your time that it was faster to do it yourself than hand-hold them through the process?
What if, despite producing more than the rest of the team combined, management saw you as a problem, and wasn't interested in your perspective now that you had a reputation?
Have you asked "the jerk" to be more polite about his feedback? Have you explained why it's important? Have you listened to his perspective?
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?
You work to raise your teammates up. Full stop. Productivity for a team is in aggregate - it's the entire teams productivity that's at stake, not an individual contributor's.
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 Greg getting hit by a bus.
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.
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.
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.
That's not how reality works. People are self-interested. The team is secondary, at best. This isn't war, it's software development.
No, you work to get great stuff done. Whether or not your teammates are a worthwhile investment (or whether they even belong at the company at all) is a complicated calculation.
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.
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.
Why would you be concerned about coworkers making "too much" in relation to you? I mean, if the company were going to close as a result of pay, then I'd potentially be concerned (more that it's a failing company or a failure of management), but I can't imagine a scenario where I would look at a fellow coworker and have it harm me any that they're getting paid well.
> "He could crank out 10 times as much work as any of us could in one day."
If this is true, it sounds like the best option would have been firing the rest of the team and looking for another like him.
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.
There's an implication later that he might have been 10x because he was cutting other people down – turn everyone else into a 0.1x developer and the 1x developer starts looking good.
I'd take that claim skeptically. But another consideration is that more than half of a team's work isn't code. You have to write the right thing, not just something, and that requires time and communication. So he might have been a 10x coder and a 0.1x communicator – indeed since he seemed to have little interest in interpersonal relations, some amount of his performance may have been due to his own time allocation choices.
Two of those people together would perform very poorly on some projects. And very well on others, depending on the clarity of the project and the amount of technical challenge it presented.
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.
In my current job, I have to deal with once certain 10x programmer with... how to put it charitably... some distinct lack of social graces. He's better than everybody else but not 10x better, also, he does not make everyone 10x dumber, thought there's some rework that everyone has to do to accomodate his demands.
I have come to believe that about half of his enhanced productivity is simply that he's a rock star and management tolerates him (but not everyone else) cut the red tape. In general, every commit has to bee peer reviewed, but he just jumps and ninja edits the code base at leisure. Everybody is supposed to run regressions before commiting, but from time to time, things will stop working and it will be some of his transactions behind it (which is discovered after multiple people could not do any productive work for half a day, trying to figure out what when wrong with their own work instead). If some tool or another is suboptimal, he will just roll out his own and be done with it (leaving the rest of the team to learn how to work with his prefered tools, instead).
Fortunatelly, we have other very strong developers that act as counterweight to him. Unfortunatelly, they also come with their own quirks of character and you are bonded to run into one of their pet issues from time to time.
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.
No matter how much two such folks might deserve one another, I'm not sure companies could afford to watch their final two coders refuse to cooperate over trivial shit like line length.
Is that the definition of "jerk" now?
I was thinking the same thing. There are diminishing returns with most jerks if they are marginally better than the rest of the team, but if they are 10x better, maybe you just need a team of 1.
One of my favorite interview stories was when I was interviewing for a very low-level dev position at a major telecom. I was interviewing to become member #8 or so on this team.
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 :)
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 :)
to their defense pearl IS a write only language... /s
Maybe, but it's also true that cranking out code is not the same as qualify software development. Lots of people can churn out code, that's the easy part.
It just sounds like that person was not a good match for the company culture. Many shops will appreciate that kind of drive and attention to detail, as well as the ability to tolerate potentially biting criticism that comes with it. I would have happily hired him away from the author's company.
> ability to tolerate potentially biting criticism that comes with it
I wonder if this is the issue really. Some people can't take criticism unless wrapped in sugar. If it's really, and especially if it comes with potential alternatives it should be socially fine, but it's not.
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.
Another aspect is how the rest of the team felt over time. They probably built up deep resentment towards this person which ultimately only fed back into the cycle. So whether or not they were aware of it, they probably formed a clique to team up against this person, again only exacerbating the core issue.
The article claimed he was a 10x and that he was usually right in any disagreement, so he probably built up resentment towards them, too.
Nothing in that story suggest ability to tolerate potentially biting criticism from other people. The story suggest ability to dish it out.
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.
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.
People that lie, who are dishonest, lazy, don't wish to work hard and look out for their interest before the company's interest are the worst kind of jerks. These jerks are seriously threatened by any kind of person who is not afraid to speak up and call them out to their shenanigans.
I've seen this before, where the team was building a skyscraper with cardboard boxes, and the "brilliant jerk" called them out and they fumed and morale was low. The jerk left and the team supposedly started meeting their goals and was releasing faster.
Well of course they were! the lone voice that was the gatekeeper was gone and all sorts of garbage was being committed to the code base. The skyscraper went up faster, and one day it came crashing down never to go up again. I was a consultant that saw this. So I always take "jerk" with a grain of salt. Of course, people should be kind, diplomatic, and caring, but they should also tell the truth and the bitter truth. I'm conflicted on the entire training thing, I believe that senior developers should teach, however, unless the company is willing to budget time for that, it is on each person to learn and shore up their skill. The company should train their developers if they are not up to par.
Work is were work happens, if you wish to learn and grow, study furiously outside of work. It's your responsibility as someone that represents themselves as a professional and asks to be paid a fair wage to learn. Some of these lessons the "senior developers" can teach are worth hundreds of thousands or millions of dollars, I don't see junior developers cutting checks to them for those lessons. Let me reiterate, work is were work happens. If you are fortunate to find a mentor that is willing to teach you, be grateful for you are blessed. If you apply for a job and the company never talked about training you, it's your responsibility.
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.
The only "10x" developer I have worked with taught me not only a ton about agile teams, but also about the liberal use of interpersonal skills in advancement of that goal. We routinely worked with education administrators (former teachers) who all had classroom experience and professional interpersonal skills training.
It was amazing to work with people you could simply expect respect from, even when everyone was well aware of the simmering annoyance and disagreement available below the surface. You just can't build the kind of momentum we saw with people who many any team member feel unsafe in their role.
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.
I don't believe in 10x developers, but I've seen a lot of 0.1x developers.
I believe I caveated the term enough by putting "10x" in quotes. I don't strictly believe in it either. This guy was great at organizing a team and a full-stack project back when distributed apps on a pure OSS stack was still a bit of an accomplishment.
haha this is brilliant
"Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds"
geeze. This is either a ridiculous hyperbole or telling of a more deep-seated problem. You should not regularly be posting changes that have room for hundreds of comments, and if you do post a change that massive, it should not be considered normal to only elicit a "handful" of comments/suggestions.
I work in a company with a strong code review culture. When I'm less confident in the correctness of what I'm doing, I'll ask for a review from someone who I know will use a fine-toothed comb. This necessarily means dealing with what seems like personal preference, but that's a small price to pay for added assuredness you're doing the right thing. Some reviewers pretty much just rubber stamp your work. That can be useful if I'm highly comfortable with the code I'm working with, but overall I don't think that is a positive or makes them less of a jerk. If anything, not taking the time to provide meaningful feedback is the jerk move.
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.
If this article were actually true, Apple wouldn't exist as the company it is today. Steve Jobs, while not a developer, was undoubtedly brilliant, and most definitely a jerk.
It's unhelpful to pigeonhole people and then extrapolate out their actions from there, because for the most part people don't conform to whatever mental model of that stereotype you've built in your head. People are complex beyond imagining.
Besides, what's the author's sample size here? One? Two? It's an anecdote worth relating, to be sure, but I think it'd be better served by leaving the "Brilliant Jerk" bit out, and leaving it as a story about team morale being more important than the contributions of any single team member.
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 think the argument is that most guys like Jobs or Gates aren't jerks. They might be a little abrasive but people often want to work with them over long periods of time.
I honestly enjoy working with those "brilliant jerks", if they are actually brilliant I will learn from them. And debating with them is very entertaining.
Same, it accelerates your growth. Can you believe OP? There he has a brilliant dev taking his valuable time to critique his and other people's mediocre work, and all he gets for it is self-protective and defensive reactions from everyone else. OP has admitted that the brilliant jerk had good reasons behind all his comments, yet here he is still complaining about it (ego much?).
There's a difference between a cantankerous curmudgeon and being an asshole.
This could be turned around: Nice Mediocre People Cost More Than They Are Worth.
I've seen a lot that socially desirable behavior is evaluated and preferred rather than people doing excellent work. Group dynamics quickly exclude these by creating a consensus of what is accepted and what the goal of the group is. This is especially easy because these brilliant people are always -by definition- a minority,
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,
This is just a strawman. No one is suggesting that you should hire mediocre people instead.
It's never fun to have a jerk on your team, no matter how good he is at what he does.
True brilliance includes the ability to recognize and govern how you are affecting others.
True brilliance includes the ability to recognize and govern how you are affecting others.
Interesting article. Definitely something to keep in mind when hiring. It's crazy how much damage one person can do to a team (and vice-versa, I've seen one person change entire team dynamics).
It's also really important to be careful with jerks who think they are brilliant, even if they are. There's always someone smarter out there and clever solutions aren't always the best solutions if no one can understand them.
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.
Alternatively, we could stop forcing the jerks to work in tightly cooperative teams. Their skills might have been useful if they would be allowed to work mostly alone.
to call anyone a "jerk" is something that only jerks do, but everyone looks at themselves as holier than thou. We're all flawed in some way. Labeling people (or attacking people) as "jerks" is in profound violation the principle of non-violent communication, to say the least, and, by the way, so is down-voting those who are critical of the prevailing opinion here without a civil counter argument ;-)
Here's the thing: some people are jerks. Calling a jerk a jerk is fine, IMO. (Some people are racists; calling a racist a racist is also OK.)
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.
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.
If not Hitler than Hannibal Lecter
My point is that we're all jerks, one way or another, just don't really know it or admit to it, but we know that everyone has done something that warrants them being called a jerk by someone. No one lives a whole life without being called a jerk by someone. I once thought Mother Theresa was a jerk for being so nice. These labels are subjective and inflammatory. and don't help the situation.
My point is that we're all jerks, one way or another, just don't really know it or admit to it, but we know that everyone has done something that warrants them being called a jerk by someone. No one lives a whole life without being called a jerk by someone. I once thought Mother Theresa was a jerk for being so nice. These labels are subjective and inflammatory. and don't help the situation.
> to call anyone a "jerk" is something that only jerks do
What about people who call "jerks" people who call someone a jerk?
:-D
What about people who call "jerks" people who call someone a jerk?
:-D
recursion limit of 0 on this stack!
[deleted]
Brilliance is not universally recognized. That is, in this case, very few people can accurately evaluate a programmer's skill.
Previously, I thought myself to be exceptionally good at my craft, and I let that define who I was as a person. Recently, however, I reconnected with an old, vagabond friend. No one in his circle could evaluate my programming competence or even cared about it. To them, I was a socially awkward, single-dimensional guy. That really shattered my bubble.
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.
This post is full of contradictions and vagueness.
> Its[sic] not that he was wrong — he rarely was
> He had good reasons, and he was more often right than not
> He just stated his opinions as fact. It was clear that he saw the world in black or white — no gray areas — and we were all wrong.
So the author agreed that he was right almost all of the time, but he should allow for gray areas? Makes no sense.
Later on:
> A funny thing happened almost immediately after he left: morale increased steadily and we actually began to meet our goals even faster with one less person on the team.
But the "jerk" was always right and "slaughtered" the code reviews of his peers, so what kind of code were they producing to meet their goals?
Maybe this guy was a jerk and didn't work well on the team, but it also sounds like the other people involved were terrible at their jobs and should either get re-educated or find another career.
> 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.
I don't think being a "jerk" is a personal trait, it's an environmental result.
Sometimes people are very picky because they are trying to stonewall you. They come up with review comments that might be accurate, but aren't actually intended to help the change land. Maybe they review just far enough to veto, and then you fix that and they review enough to veto again. That kind of jerk is not worth much, but it's the malintent behind the impolite behavior that is the problem. Often the person is disengaged and disinterested in their job.
Sometimes people are become defensive and difficult because they don't believe they are contributing enough compared to their past performance. I've seen a lot of people who did a lot of good work in the past, but aren't doing well now. Maybe processes changed, maybe how the team makes priorities changed, maybe technologies changed, maybe they aren't managing themselves well, maybe they are just depressed and having a hard time functioning. Maybe it's compounded because their own displayed confidence backed them into a wall, and they can't admit there's something they don't know or aren't able to do, and so they can't learn to do it. These jerks are "essential" (because they know stuff, maybe have authority), but not productive. Sometimes they stonewall to hide this.
There's jerks who have their own agenda that doesn't align with some of the people they are supposed to work with. It a matrixed organization everyone validly has independent agendas that cross with each other. Maybe they only feel personally responsible for product quality, while they are a gatekeeper for people who are supposed to deliver new functionality. Because of how authority may be setup, someone may feel trapped between two authorities (their boss and this gatekeeper) with no way to come to agreement on priorities. Usually this is a lack of understood overarching priorities from leadership. Sometimes without that in place the only way to "win" is to be difficult.
Personally I don't have a problem working with abrasive personalities so long as we truly share a goal and are working towards it. Having a group of people who really share a goal is not as common as one would hope.
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.
I have created some companies and managed lots of people.
In my experience, the moment I hear someone calling someone else "jerk", it tells me more about the person telling it than about the "jerk" itself.
In particular it tells me you as manager can't handle this people, and you are incompetent as manager and need to improve you handling people's skills.
It is something similar to Cesar Millan working with dogs, but instead of Cesar visiting dog owners that do not have a clue about the dogs they have,it is a similar process with people. I am somewhat of a "natural" managing people but also studied practical phycology for years in order to understand and manage different people and I can testify that most managers are so clueless in the practical side of things(they probably studied the things they don't apply in practice).
A "no brilliant jerks" policy is the best thing you can do for your competitors that know how to handle them. Call it "Always live in your comfort zone""Do not learn" policy. Go for it.
I personally love to welcome those jerks in my company and fix their traumas with clueless managers. It is also very profitable, you make money doing good and feels very satisfying at the end(after the work of fixing the traumas).
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).
Hey, you sound like a jerk:
- stating your opinion as fact
- not trying to mentor or give learning opportunities
- relying on being 'right' (I'm rich and successful because I manage jerks the right way)I was a jerk at my last job (btw, I'm not saying I'm brilliant either). It ended up costing me and I was shown the door. However, I was picked up by some former co-workers that knew I had some talent.
Now I actively manage my "jerk" tendencies. While I still have my jerk moments, I think my co-workers realize that I'm trying not to be a jerk so they let it slide. And when I am being a jerk, they will call me out on it.
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.
People responding about how they personally aren't bothered by jerks are missing the point. It's great if you have thick skin, but it's hard enough to hire quality engineers without having to stipulate that they must also be psychologically hardened against lazy, petty, or oblivious aggression from coworkers (i.e. jerky behavior).
If I can choose to hire one brilliant jerk or three merely "good" engineers who don't need to be reminded to treat their coworkers thoughtfully, then I take the three engineers every time.
Arguments pointing to famous productive jerks (e.g. Linus Torvalds) also miss the point. Sure, Linus's prickliness may actually be a benefit given his singular position, but it's just that -- singular. You'll notice that no one else in the Linux dev community gets lionized for their random acts of rage. The world can tolerate a single Linus, but the solution doesn't scale, especially not to a random work group at a tech company.
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.
There's room for exactly one hyper inflated ego in the Linux kernel development team. If you are not Linus, you are 25 years late.
"Hatred is the coward's revenge for being intimidated."
― George Bernard Shaw
Been there. Was involved in a telco software project where one person was a genius, a true unicorn. We were in meetings where some of his insight and perspective left us scratching our heads in amazement. Yet he was the most destructive co-worker I've ever come across.
He never did anything. He would belittle others if they didn't grasp things. He would see a well-layout project plan and laugh and say that he could do it in a weekend, and management would listen because of his intellect and dominating presence. Every request for him to actually do any work was met with a 'too busy' answer, yet he would berate others for not meeting schedules.
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 what's the best way for people like that to apply themselves in your view?
Despite his intellect, he was a child really and his only hope was for management to rein him in and focus on deliverables (which they did not).
I worked with a brilliant jerk. He's a MD PhD w/ a 160+ IQ, sometimes yells at colleagues in meetings, and can do things nobody else can do. Wouldn't trade the experience for any I can think of.
So why he was a jerk?
"Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds. Most of the comments were opinion and personal preference."
So he saw more problems in the future than the rest of you and maybe your comments about his comments are opinion and personal preference. How do we know the truth?
Anyway, this article is a proof that indeed B players never hire A players. Because they don't get it and they take everything personal.
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.
Netflix has a "no brilliant jerks" policy in the culture deck[1], which people are encouraged to read when applying to work here. The policy works great. Just because some brilliant people are jerks doesn't mean all are.
http://www.slideshare.net/reed2001/culture-1798664/35-Brilli...
http://www.slideshare.net/reed2001/culture-1798664/35-Brilli...
Two obvious counter-examples: Steve Jobs and Linus Torvalds.
10x programmer who says what he thinks, gives brutally honest feedback, doesn't couch his facts behind euphemisms or nice-guy behavior, and has extremely high standards for code quality? To many people, this description fits Linus to a T.
And even if you dispute the characterization of Linus as a jerk, Steve Jobs certainly was. I don't see how anyone can hear stories about the way he treats his colleagues and employees, and not admit that he's a jerk.
Did Linus and Steve cost their respective organizations/missions more than they contributed?
I think a more balanced answer to the value of jerks is... it depends. Some brilliant jerks, if put in senior enough roles and given sufficient influence, can produce outstanding work-product. Outstanding enough to justify the loss of morale and attrition all around them. But if you're going to hire a jerk and expect him to be another cog in the machine, he's much more likely to gum up the works instead.
Some roles require rare and outstanding talent above all else. And other roles require someone who can follow orders, work well with others, and not rock the boat too much. Whether or not you should hire a brilliant jerk, really depends on which type of role you're hiring for.
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.
It's less likely that there's a team of people who are abnormally sensitive to criticism than one person who is uncommonly abrasive. In this case likely the jerk's output was not worth his externalities.
In general I think the externalities of having "No Jerks" tend to put a cap on an organizations success. While they can be tough to deal with they challenge the status quo. This is key if you are to avoid local maxima. In abstract a company is a hill climbing algorithm in the space of success; without noise in the system you are very likely to get stuck in a local maximum. Too much noise and you might never climb.
It's not necessary to be a jerk to succeed, and it's not necessary to be a jerk to fight the status quo. I do however feel a strong correlation between these traits and being a jerk. It's all well and good to search for the right people to perfect the mix but you'll always have to settle eventually, don't be afraid to settle on someone who's a little hard to get along with if they add something else key to the mix.
Simple rules are useful because they're easy to follow; but all rules have externalities. If you're following "No Jerks" to the letter I'm not sure they're are worth it.
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.
The thesis being argued here isn't supported by the poor anecdata.
> Every time one of us would post our code for review, he would slaughter it. Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds. Most of the comments were opinion and personal preference. He had good reasons, and he was more often right than not, but he never even tried to be kind. He never took the opportunity to teach or mentor. He just stated his opinions as fact.
> [...] At first the rest of us tried to have constructive conversations, then we often just gave in, then I realized that we were actively avoiding him altogether and skirting our process. [...] He was so good. Was it worth even arguing or talking to our manager about him? Surely if we just put up with his attitude, we’d accomplish more because of the sheer volume of his contributions.
The solution here is indeed to talk to the manager. A brilliant jerk with strongly held opinions about code should be pretty easily convinced based on efficiency grounds. Repeatedly leaving hundreds of detailed review comments is not a good use of time, while writing up something that could be referred to that explains the reasons for the coding standards would prevent such comments from needing to be made in the first place (and could be used by others to distinguish stylistic preferences and opinions from truly necessary standards). Repeatedly having the same "constructive conversations" is an even worse use of time.
While I'd question the "brilliance" of somebody stating "opinion as fact", someone leaving hundreds of comments in a code review clearly cares and thus can be reached by an argument grounded in the things he cares about.
> 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.
If he really was a 10x engineer and it was a "small team" (say 6 people), wouldn't firing the other 5 have been the better move?
Sometimes yes, but there is the question of budget. If that was a project or contracting work, and the client can be sold 6 people, then it looks like bigger work, and can be charged more. If you just put one brilliant dev to do it, the client might not be convinced that the job is as big as you tell him. Sometimes devs are put on projects just to "sit it trough", they are needed for the headcount.
Maybe it's just me but most truly brilliant people with whom I've worked, have been the opposite: very nice. They were not only smart in their own field but also smart on an emotional level. They were the kind of people you wanted to be around, and they were constantly learning from other brilliant people, recognizing that a bad personality creates friction to learning.
Maybe that is because you're positive and open-minded enough to concentrate on their good qualities and not to perceive them in passive-agressive way as 'jerks'? :)
IMO the 10x productivity thing is a bit of straw-man. thats rarely the case. but realistically its more like 3-4x. I'd include one crucial factor in evaluating this that I always look for in new hires, its Ownership! Do you have commitment to your responsibilities or is it just about finding immediate gain (could be ego for brilliant jerks or security for mediocre lazy bum). IMO in long run if you are about avg you will converge on the 'right' solution if you are looking for it. the problem IMO is many engineers have weak sense of ownership of what they do & based on their capabilities they adjust their behavior.
I'd factor in the motives behind being jerk before judging. Is it that they are just mean egotistical person whose using his technical superiority or there is genuine desire to make things better even if it means 'breaking a few eggs' in short-term?
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?
I worked with someone like that once and it made me conclude it does not really matter whether the intention is good.
If code review forces you to adjust hundreds tiny details according to someone elses preferences and opinions (as opposed to when you have something really wrong), you can not take ownership of that code. Because it is not your code in the first place. If you want people to take ownership and responsibility, you need to allow them to do so - not really possible when top dog is micromanaging them.
Imo, the developer in question should have work alone on some core part of the project he would have responsibility for and not do code reviews frequently.
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.
Funny that he complains about "jerk" seeing world as black-and-white in article that categorises people as jerks/non-jerks without any mention of in-betweeners.
Also what if the "jerk" is actually right? What if he is truly surrounded by incompetent people and needs to push things himself, repeating himself all the time, his suggestions being ignored or simply not understood or completely outside of intellectual capacity of his colleagues? What if perceived progress after firing him is illusory. Created by banal steps and pseudo milestones. What if the "progress" in few years perspective will mainly mean running in circles without adding any real value, just code debt?
Good manager wouldn't let go person like that, he can always jump into R&D, creating prototypes of systems/ideas alone or with somebody matching his competence.
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.
I don't like to defend a jerk anymore than the next person but I can play the devil's advocate here.
If he's a 10x developer he's going to be a genius. A genius is a person who sees the world in shades of grays. He can't help it. If he's of that caliber then it's built into how his brain works. The comment about him being both a 10x developer and someone who sees in black and white is generally off. However, if he's looking at the work of an average person or even just an above-average person, he will ten to be able to see stronger shades of grays than other people because of his high aptitude. This is possibly why he appears to be someone who sees in black and white.
Overall the author of the article borders on anti-intellectualism... which can easily veer over to anti-semitism.... the frequent opponent of Linus Torvalds.
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.
For whatever reason I feel like there's an unspoken assumption in our industry that a dev is brilliant iff that dev is a jerk, which is clearly false (I'm sure everyone here has worked with devs who were brilliant at both coding and social interaction). Note how the article has to explicitly say "it is entirely possible to be extremely passionate (and even brilliant) without being a jerk", as though this were some rare intersection of talents. But brilliant non-jerks get to choose where they want to work, and they're going to prefer not to work with jerks. If you need really need a bulletproof business excuse to convince you to tell the assholes on your team to cool their jets, then do it so that you have any chance of attracting non-jerk talent.
Honestly, I was always happy to have good developers. The better you are, the bigger pain in the but you can be, as far as I am concerned as long as the code you are delivering is excellent. I am perfectly happy to work around your quirks, within reason of course.
And, of course you will be a jerk when you are seeing things others just can't and they can't understand you. After a while you lose patience.
What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
So two essential qualities in my view are: being really good, have excellent foundations and being open to learning and coaching if you don't have those.
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.
That's where mentorship comes into play - mentoring the rest of the team has greater effects than trying to plow through code over the long haul. The reason is that it creates a silo that the one high producer gets saddled with, and it creates a bottleneck that ultimately probably will even result in the high producer becoming unhappy due to being distracted with all of the maintenance burden from his/her code.
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.
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.
> What good developer can bring to a team is more valuable then 3-4 polite junior devs that have enthusiasm (which I value also highly) but can't produce quality stuff.
All good developers were less-good junior developers once. What I value most is the good, patient developer that turns all the developers around him into good developers over time. They're far more valuable than someone with a high production rate but who drives others away.
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.
That all sound good but in practice rarely is the case. Good developers and every kind of smart people, scientists, are eccentrics, because they just know more then you and it is hard to explain everything every time.
> Good developers and every kind of smart people, scientists, are eccentrics
Not always, and "eccentric" doesn't mean "unable to be helpful or kind".
> because they just know more then you and it is hard to explain everything every time
Yes, it's hard. It's a different skill than programming or general intelligence. And it's a harder skill to find or to train. As a rarer skill, it's thus more valuable, and more useful to select for. And as an engineer, developing a rarer skill makes you more valuable, which will improve your career prospects (in both pay and position).
Source: I've been on both sides of numerous performance review processes, and seen what people value at many levels of a technical job ladder.
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.
I think it is important to match coworkers by their caliber. You're right, if you have one really amazing developer and a bunch of mediocre developers that one really good developer could become bitter.
Seems like the case here, if someone is leaving hundreds of opinion-based criticisms of someone else's work that's a pretty clear indication of dissatisfaction.
>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 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.
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.
Why does everyone insist on comparing the jerk to junior developers? Why does everyone insist that, in order to avoid jerks, you can't hire talent? There are plenty of good, talented people who are not jerks.
The other side of this is worth considering: I'm no 10x developer, but I've recently been the only developer with some experience working with a team of others with none (interns.) Simple things that most with more experience would take for granted, like version control, must be explained at length to a beginner. Do this enough times and it's easy to skip explaining things, prompting such articles from them.
Sometimes, before you can realise the factual superiority of a process/technique, you need to trust someone else's opinion on it. It is only later that you can understand why. This makes sense to me, because this is how I learnt when I was starting out.
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.
I don't think there's a causal relation between brilliance and jerk level, but:
It's a sliding scale. Does the contribution of the jerk outweigh the loss of contribution from people offput by his attitude?
Linus is a jerk, and while Linux might have been even more successful if he wasn't, that isn't who he is. Should we ignore the success of Linux just because the original creator can be an asshole at times?
I'd much rather work with a brilliant nice guy than a brilliant jerk, but sometimes you don't get that choice. Sometimes your choice is a brilliant jerk who has the vision, drive, and ability to succeed at whatever your goal is, and a nice guy who doesn't.
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.
We're in the business of shipping working things on time. I'd take the "brilliant jerk" over most alternatives.
Grow up, ignore the jerkness, and enjoy the code. Seriously - great developers are so rare anyhow.
Grow up, ignore the jerkness, and enjoy the code. Seriously - great developers are so rare anyhow.
Can't the same advice be given to the jerk? Grow up and stop being a jerk?
And really, if we're in the business of shipping working things on time, do you think it's a good idea to keep someone on who's going to bring down the rest of your team, or drive them away?
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?
There are two types of "jerk but productive" and what separates them is whether they are willing, even on the lookout, for things to learn from their more junior colleagues. Example:
Un-curious jerk: please don't write anything, even developer tools, for this company is node.js; I heard it's still riddled with bugs and I wouldn't touch it with a ten foot pole.
Curious jerk: we can't build any official tooling with this stack yet, but for a couple minutes could you show me how you were taking advantage of the asynchronous capabilities, I heard it has killer support there?
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?
I wrote about a similar problem a couple of years back. I called it the "hero anti-pattern".
https://mikeseablog.wordpress.com/2015/02/26/the-hero-anti-p...
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.
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.
It's difficult to tell from one single viewpoint.
However what I find MOST revealing is that there is precisely ZERO mention of 'training' anywhere in the article.
Did they not attempt to train the 'jerk' to be less harsh while still effectively communicating?
Did they not attempt to train the possibly overly-sensitive employees to step back and try to not take everything as a personal attack?
I think that /both/ things would have enriched the value of their employees. Both those who need more guidance on being better at communicating and those who need to improve their technical skills.
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.
On the subject of making code reviews a positive experience I think it has been helpful where I work to explicitly discuss code reviews. What makes a good code review vs. a bad one. For example the idea that code review comments should be based on the substance of the code rather than style.
This stuck out to me as I tend to be very critical in code reviews, which I think made other developers uncomfortable. By talking about it though I was able to soften my approach. I was also able to make sure my language came across as reviewing the code, not the developer.
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.
While I don't doubt the author's employer did the right thing – to fire the individual – I think the subsequent logic (e.g. guard against "jerks" at all costs!) is a dangerous train of thought, one which is more likely to pigeon-hole human beings.
In reality, no person is "simply a jerk". Each of us sits somewhere on a spectrum of intolerance towards others for one reason or another. It's healthy to learn how to work with people of all stripes – even individuals who can, at times, be abrasive.
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.
See also this discussion in response to an article "Emotional Intelligence is overrated"
https://news.ycombinator.com/item?id=8389065
and let me dupe my comment to that:
Without falling on either side of the debate, it's probably a good time to bring out this quote from 1704.
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, 1704When the whole team feels uncomfortable as a result of one person behaviour, it's time to get rid of this bad apple—total output will be bigger than one person being brilliant and the whole team unproductive.
For 10 years I had outsourcing studio and once one of my programmers was that bad apple. At first he was nice, but then in couple months showed his real character. After four months of pain for everybody I fired him. Never again would I tolerate such situation.
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.
Articles like this one are counterproductive for not trying to understand the root core of the "jerk" behavior.
There's no such thing as a team where everyone on the team is on the same level - there's always some distribution, this guy has decades of experience and is brilliant, this guy is a junior straight out of college. To every brilliant person on a team (and every team has someone who is relatively brilliant, again because it's a distribution), the people at the other end of the distribution are dead weight. The question is about the personality types of the people on the team and the way that management decides to deal with them.
If management doesn't put the brilliant people into more senior roles, where they are directed to mentor lower-performing people to try and bring the entire team up to a higher performing level, then management is backing the status quo. This breeds frustration and resentment on the part of the high performers.
If management does get the high performers to mentor the low performers, but low performers fail to show improvement, it's management's responsibility to ask why? Does management need to help guide the high performer to help him become a better mentor? Or is the low performer a low performer not because he's inexperienced but because he has no drive for self-improvement? If the low performer remains a low performer over time, why is management keeping him on the team?
Too much management philosophy is falsely dedicated to "feel-good" practice. If your team feels good, then they will be motivated to work for you, and will work at their maximum potential for productivity, and succeed. Team happiness is, of course, important, but so many happy teams fail because happiness is not a cure for mediocrity, and their mediocre products are outcompeted by better options on the market.
What management really needs to ask is whether brilliant jerks are jerks because they enjoy belittling others, or are they jerks because they're frustrated at the team's mediocrity and genuinely desire for the team to write better code? If it's the former, then yeah, get rid of them, they're toxic. But most of the time it's the latter, and their the blame for their frustration lies not with the 10x programmer, but with the manager, for trying to inculcate happy teams instead of productive and effective teams.
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.
Sure I bet management goals are met in the short term, but you have to wonder at what level of quality now that they are left to their own devices. Fixing defects after release is 10-25x more costly than if found during construction (McConnel 2003 - Code Complete). How much do you want to bet that removing that brilliant dev that was finding all the issues is going to cost that project much more than they realize.
So, the specifics:
- The guy takes his time to offer high quality advice
- The guy offers a lot of high quality advice
- No real specifics are given on _why_ he's a jerk
- Higher throughput is taken as a proxy for better performance without accounting for quality, NFRs etc.
This piece - while interesting - doesn't give the information necessary for the reader to arrive at an independent conclusion.
This piece - while interesting - doesn't give the information necessary for the reader to arrive at an independent conclusion.
[deleted]
Definitely. Still the case in the post represents a very soft version of the type, comparing to who you can really come across at work.
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 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 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.
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.
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.
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.
The book "The No Asshole Rule" covers this topic in length.
Not all jerks necessarily brilliant, productive or successful. But the "culture ruining" jerks are the ones that become an example for others to follow, or sabotage people with potential to make room for themselves or their friends.
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.
I've worked with people who think mocking the personalities of developers is a form of team-building. The toxic competitiveness is seen as some kind of incentive for personal growth. Football players are paid to win, not growl.
It's all about chemistry. Without it, work isn't fun. In this case, removing him helped restore it, so that's good.
There may be teams that can take a jerk, perhaps with a "handler" (in the team).
There may be teams that can take a jerk, perhaps with a "handler" (in the team).
There are just as many, if not more, situations where it's the rest of the team that actually can't handle the so-called "jerk" by being overly sensitive and defensive.
"Brilliant jerk," hmm, the term I always had in mind for our CSO was a brilliant sadistic sociopath. I couldn't help but admire him, but man, he loved to ruin my weekends.
Opinionated people can often be jerks, they don't work well in teams, but that quality might be what makes them exceptional. Maybe let them work the night shift :)
This discussion is a little bit too abstract. So I am going to take advice from Richard Feynman (who famously asked philosophers about a brick), and ask:
Was Richard Feynman a jerk?
Was Richard Feynman a jerk?
Can confirm - it's true. I was one few years ago, made conscious effort to cleanse that attitude of mine. Feels so much better!
If I sum it up:
1. They did not manage to improve themselves a bit thanks to "the jerk"'s remarks, since the number of remarks (that he calls justified remarks) did not decrease.
2. They are now happy to deliver quickly. They don't give a fuck about the fact that they now deliver shit, and they are happy with the fact they didn't learn anything.
1. They did not manage to improve themselves a bit thanks to "the jerk"'s remarks, since the number of remarks (that he calls justified remarks) did not decrease.
2. They are now happy to deliver quickly. They don't give a fuck about the fact that they now deliver shit, and they are happy with the fact they didn't learn anything.
So what is a jerk? I know this article is probably a fictitious rather than about a specific individual, but seems like if he really was a "10x"er he'd be an asset to the team and reasonably intelligent people could see that.
This guy was communicating the best he could... "Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds." Sounds like he's trying. I assume it takes a lot of his time to generate comments like that... if he was right, I'd want the team to be following his advice and that should help reduce the number of comments review over review.
To me... a jerk is someone in legal who says with a smile, "Sorry we were holding that information about us acquiring that other property until now... and we need the new system up and running by Monday." Or someone on the design team who just refuses to switch his designs from points to pixels or pixels to points or whatever it is the current site is using and then bitches about how it's 1/2 a pixel off in production. Or that guy in sales who tells me that the product is shit because we haven't built the one feature his important prospect really wanted... Someone who doesn't care that they are making more work for me, someone who doesn't care about the job I have to do.
Someone who is doing a huge code review... with copious amounts of feedback... man, I'd love that! Sounds like he really cared and is being quite thoughtful. I think with the right manager and process the team could improve.
Management layers exist to help setup processes that act as lubrication -- so if someone is just good at his job and rubbing people the wrong way... that's 100% a management problem.
Having dealt with this exact problem in just about every position I've had as an adult... I think the solution is to pull aside the offended people and make sure they know how I see them -- I'd explicitly point out what I agreed with and offer praise about their production where warranted. I'd encourage them to parrot back some of the behavior towards the offending person... if they didn't feel comfortable, they could let me do it for them.
I'd pull aside the "jerk" and bluntly as I could explain why it's important to be more political in dealing with others on the team. I'd make sure some personal issues weren't going on and that he knew it wasn't appropriate to be mad at people at work because his wife left him, etc. I'd make sure we did reviews every sprint (or at least every cycle) where others got to review him, and I'd read those back to him. I have literally never found a "jerk" who couldn't be reasoned with, or explained away. I had one amazing dev who was pretty far down the Asperger spectrum who loved calling people a "fucking dumbass" and eventually it just became part of the culture on that team to lovingly call everyone a "fucking dumbass" -- we even had t-shirts made. Looking past what is said to the intent... most "jerks" aren't trying to hurt feelings, they just take pride in their work. Give me people who care any day, we can find a way to work them into the team.
Be careful that "morale increased steadily and we actually began to meet our goals even faster with one less person on the team" isn't just diminished expectations in disguise.
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.
It sounds like you just fired Steve Jobs.
The bit about improved productivity seems dubious.
One of the problems in this industry is that a lot of teams have no real measure of their actual productivity. We have scrums and points and velocities, but seldom have any way to know how this actually compares to other teams, or any other benchmarks.
I've been dropped in on teams that had spent long periods (in cases years) creating trivial solutions. They were productive in their own way, generating huge volumes of code, had a great sense of satisfaction about their process and a sense of accomplishment, but what they were creating was a week of work for a single person if correctly built. And they happily enjoy their synergy until they are outsourced or eclipsed by competitors.
Maybe I'm sensitive. I've been "the jerk" before. I once had a coworker complain to HR and my boss because she felt that I was domineering. I was domineering in this case because I had opinions and expressed them to the team, and their opinion and suggestion of a new process was that we should have "opinion roundtables" where each participant gets the same amount of time to talk with a timer, etc, and need to suppress any suggestions or opinions outside of that period. I left that team and organization, and eight months later the team was fired.
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.
Following combination would slow them down: "Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds." with "Most of the comments were opinion and personal preference. [...] He never took the opportunity to teach or mentor. He just stated his opinions as fact."
That sort of behavior generates a lot of work to the rest of the team - time spend changing the code, time spent discussion opinions and trying proactively writing the code in way that will pass his review. Time spent being confused over why this or that was wrong again (since it was not wrong actually). If those less experienced people feared him, which is likely, they spent a lot of time attempting to anticipate his opinions and preferences (while sacrificing their own opinions and preferences even when they were right).
Moreover, people like him would cause other experienced people to leave. While junior might be fine with being expected to submissively conform to someone elses preferences that much, experienced person wont. "You are doing it wrong" might work on junior, but not on someone who knows that he is not doing it wrong. Anyone who is willing or wanting to take on responsibility would leave.
Yet moreover, he likely regularly shot down good ideas of other people, which would make those other people more passive. It is the same effect as why micromanagement has.
That sort of behavior generates a lot of work to the rest of the team - time spend changing the code, time spent discussion opinions and trying proactively writing the code in way that will pass his review. Time spent being confused over why this or that was wrong again (since it was not wrong actually). If those less experienced people feared him, which is likely, they spent a lot of time attempting to anticipate his opinions and preferences (while sacrificing their own opinions and preferences even when they were right).
Moreover, people like him would cause other experienced people to leave. While junior might be fine with being expected to submissively conform to someone elses preferences that much, experienced person wont. "You are doing it wrong" might work on junior, but not on someone who knows that he is not doing it wrong. Anyone who is willing or wanting to take on responsibility would leave.
Yet moreover, he likely regularly shot down good ideas of other people, which would make those other people more passive. It is the same effect as why micromanagement has.
I have never had a good job. Most of my life has been miserable working in QA and not finding any value in anything I do or being able to find something better.
This currently leads me to where I am today, working at a huge corp in a pool of mediocrity. The people around me have absolutely no big ambitions to do anything meaningful in life and are very comfortable with their mediocre kids. These people are happy which is a whole other topic that blows my mind.
Because I am constantly around these people, they think of me as mean and condescending. No I am not, I just can't be happy producing shit work in a company that doesn't provide me with any value. When I go home, I am not going to have fun, I am going to work on a project that can help me get away from these people. I don't allow anyone to passively say "tgif" or "its monday" to me as if I agree with their mediocre sentiment.
Maybe I am mean and that is why I can't find work, but I rather be mean than mediocre.
This currently leads me to where I am today, working at a huge corp in a pool of mediocrity. The people around me have absolutely no big ambitions to do anything meaningful in life and are very comfortable with their mediocre kids. These people are happy which is a whole other topic that blows my mind.
Because I am constantly around these people, they think of me as mean and condescending. No I am not, I just can't be happy producing shit work in a company that doesn't provide me with any value. When I go home, I am not going to have fun, I am going to work on a project that can help me get away from these people. I don't allow anyone to passively say "tgif" or "its monday" to me as if I agree with their mediocre sentiment.
Maybe I am mean and that is why I can't find work, but I rather be mean than mediocre.
Are you sure you are not projecting your own attitude on them? I know testers who like that job. Not like as "I want to become famous", but like as "I actually like doing that activity and like people on that job".
To address the personal attack in second paragraph: Some of those dudes might consider their families meaningful. It is goods for kids when their parents love them even as kids are average - most kids are average so it is good when parents are comfortable with them. There is nothing wrong nor shameful about men being comfortable with their own children. Fathers are as important for children as mothers.
To address the personal attack in second paragraph: Some of those dudes might consider their families meaningful. It is goods for kids when their parents love them even as kids are average - most kids are average so it is good when parents are comfortable with them. There is nothing wrong nor shameful about men being comfortable with their own children. Fathers are as important for children as mothers.
What does your comparison about mothers and fathers have to do with anything?
"If you hate a person, you hate something in him that is part yourself. What isn't part ourselves doesn't disturb us." - Hermann Hesse, Demian
"Everything that irritates us about others can lead us to an understanding of ourselves." - Carl Jung
Playing high status at work could be a coping mechanism. Honestly, if you're unhappy just quit and go work someplace where people are smarter than you are. But if this feeling persists, its probably time to change yourself.
"Everything that irritates us about others can lead us to an understanding of ourselves." - Carl Jung
Playing high status at work could be a coping mechanism. Honestly, if you're unhappy just quit and go work someplace where people are smarter than you are. But if this feeling persists, its probably time to change yourself.
What does being smart have to do with anything?
Smart doesn't equal interesting. Plenty of smart people around me.
Smart doesn't equal interesting. Plenty of smart people around me.
Ok, more interesting than you are.
I spend my nights and weekends working on side projects in the hopes that I can find a job that I like. I have been applying to jobs nonstop since becoming an adult and will continue to do so until I find something that will make me happy.
I definitely do these things constantly in the hopes of finding something that will make me happy, but after almost 10 years and nothing really to show for it, it can cause someone to go insane.
I definitely do these things constantly in the hopes of finding something that will make me happy, but after almost 10 years and nothing really to show for it, it can cause someone to go insane.
The real question is, what have you done recently to improve your skillset? If you regularly improve your skills, you won't be in that situation for long.
I don't agree with this. It is really about who you know. I never got a job because of skills
Do you not have any skills? lol
People want to know you because you have skills. If you don't have any skills or assets, people will drop you like a hot bucket.
People want to know you because you have skills. If you don't have any skills or assets, people will drop you like a hot bucket.
Of course improving skills is always essential in anything in life. That doesn't help you get a job.
It's hard to be unbiased while being introspective, but I suspect I might be a bit of a jerk. I don't berate people, but I get frustrated easily with what I consider to be manifestly stupid choices. It's worth noting, then, that the most successful and productive teams I've worked on have been where everybody was a bit of a jerk. We could give each other shit without our egos getting in the way. We knew that it was just banter. It's kind of like how guy friends rib on each other all the time without it hurting their friendship; there's a certain baseline level of criticism that's enough to convey useful advice but not so much as to make people feel like shit. E.g. "Kenny, what the fuck is this loop supposed to do?" Is more effective than "I feel like this could be written more clearly."
[deleted]
The jerk referred to in this article should probably be tasked with more solo tasks. That is the solution. Not to get rid of the jerk, but to give them more freedom and distance from teammates. A person like that should also have more say in what they are working on, ideally, I think.
If the guy was so good, why didn't they promote him?
Individual Contributors gotta contribute individually
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.