[sporadicism]

> Most of my peers would rather work with brilliant jerk than a friendly average person

I worked with one of these. Every interaction was miserable and stomach-turning. He slowed the project down in a number of ways. A friendly average person would have been a net gain.

[shiroiuma]

>A friendly average person would have been a net gain.

I'm perfectly happy to have a friendly, average person as my boss, as long as he has good people skills and is pretty good at managing a team. He doesn't need to be technically brilliant at all.

By contrast, working with a boss who's a technically brilliant jerk is an absolutely miserable experience. Companies that make a habit of promoting brilliant jerks into management positions should be avoided.

[JohnLeitch]

What was his role? How did he slow the project down? I ask because quite often, the value of "soft skills" is exaggerated. In almost 20 years of software engineering I have met some of the worst personalities imaginable. Yet, I cannot think of a single time somebody's personality got in the way to such an extent it slowed the project down. Some problems can't be solved by average people. In such cases, bad social skills with above average intellect will go farther than average intellect with good soft skills.

[whstl]

I know an example. A tech lead who would demand every single task to be done in certain ways and go through a certain processes. Invading other team's PRs and slack channels in order to pick fights because they weren't using his microservice or his libraries. Claiming "if you're not working like us, then you're wrong". Asking people to make PRs but then not approving. Before being demoted, his team had ZERO new features delivered for about a quarter. To me that's an example of slowing down teams.

But if you mean you want someone "brilliant, but an asshole", then I agree with you. I find that the common examples are more about incompetent managers who can't make the best of an IC who can work well in isolation.

[ragall]

What you describe is definitely not a person with hard skills, so it's not relevant to the current discussion.

[whstl]

I was answering to a specific post that doesn’t mention or imply it, plus I mention exactly what you say in my second paragraph which you most certainly missed.

[willhslade]

Not OP, but I did work for a boss once that was technically very strong, but not as strong in terms of planning and scheduling work. It was a very difficult process, because I couldn't deliver what they wanted, as what they wanted changed both during and after delivery. Most things I delivered, which were what we agreed upon before delivery, were rewritten as they did not envision or plan work in advance. Technical skills are not a panacea; professionalism is a multidimensional skill matrix.

[shiroiuma]

Exactly: being able to quote esoteric facts and trivia about CPU instruction sets or compiler features and use those while working doesn't automatically make someone adept at planning and leading a team of developers. However, some companies think the opposite, and the end result is not good.

[baka367]

Every PR has to match their way exactly.

The logic, the method names, the test names, code in the log messages.

Does not matter what the output or complexity is, does not matter how the previous state of the code in the area looks like, it. Must. Look. And. Read. Their. Way.

A 3 file PR review can take weeks. There was once a PR for a new feature that took 1.5 years and 2 developers (the og op left the company 3 months into having opened this PR) to eventually merge.