Earlier quoted context omitted.
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 hav…
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…
Brilliant Jerks Cost More Than They Are Worth
181–190 of 279 posts
Re: Brilliant Jerks Cost More Than They Are Worth
#182Earlier quoted context omitted.
> 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 ar…
> Brilliant jerks are often to be found at the beating heart of successful software. Survivorship bias doesn't render this an ineffective argument against the simple "no jerks" policy argued for in the article. The contention is "(jerk present) → ¬ (success)", aka "¬ (jerk present) ∨ ¬ (success)". A single case of "(jerk present) ∧ (success)" is sufficient to disprove the direct implication.
The contention 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.
Re: Brilliant Jerks Cost More Than They Are Worth
#183IMO 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 w…
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.
Re: Brilliant Jerks Cost More Than They Are Worth
#184Earlier quoted context omitted.
> 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 ar…
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 b…
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
Re: Brilliant Jerks Cost More Than They Are Worth
#185Interesting 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.
Re: Brilliant Jerks Cost More Than They Are Worth
#186> "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.
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 c…
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.
Re: Brilliant Jerks Cost More Than They Are Worth
#187In 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.
Re: Brilliant Jerks Cost More Than They Are Worth
#188Re: Brilliant Jerks Cost More Than They Are Worth
#189Earlier quoted context omitted.
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 hav…
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…