The latest The Workplace question to inspire me to write a whole post is How do you counter the argument that “Arrogance isn’t a blocker”? I don’t understand why a professional would ever say that arrogance isn’t a blocker, but I’ve sure got opinions on how to counter that argument!
First of all, software development is a team sport. Sure, side projects and prototypes can be built by individuals, but the vast, vast majority of business software is built by teams, which means that communication is everything.
Are you going to go out of your way to communicate with the arrogant jerk on your team? No you are not. Nobody does that. Even if you really need to you’re going to put it off as long as possible. Yes that’s not ideal, and you can make the argument that it’s illogical, but let’s be real, humans have emotions and we don’t like dealing with jerks. To have good communication on your team you have to make it as painless as possible.
Arrogance is also a literal blocker to ideas. Arrogant jerks make people scared to speak up about ideas they aren’t completely sure about because they don’t want to make themselves targets. The bigger the jerk the more scared people get until nobody speaks up at all. Jerks also make people scared to try things – if a jerk is looking for any excuse to shit on you of course you’re not going to try anything that could possibly fail. With a bad enough jerk, nobody on the team grows as a programmer because they never try anything they haven’t done before.
Jerks also make your team avoid code reviews, at least if the jerk is involved. Nobody wants to hear that everything they built is terrible and the jerk could do it 1000 times better even if there are a couple of valid needles in the haystack of outright meanness. You can be sure no one will volunteer to review the jerk’s code either, which means standards start slipping, bugs may get into prod – not because code reviews are specifically about finding bugs but because code reviews are great for catching “this is really complicated and I’m having trouble following it, can you pull it apart and simplify it?” and that prevents bugs – and if somebody needs to change the jerk’s code nobody will know where to start because nobody reviewed their code.
And a jerk’s code often really needs reviewing. In my (thankfully limited) experience, jerks who think they’re smarter than everyone else write overly complicated code that no one else can follow to prove how extraordinarily clever they are. This has been known to backfire when it turns out that not even the oh-so-clever jerk can follow that code. Even if anyone is willing to review a jerk’s code, it’s not likely to improve that code because jerks rarely take feedback well. If they did, they’d stop being jerks!
Yet another way jerks harm your product is by ramming their ideas though by making every disagreement or discussion a huge fight. Eventually the rest of the team will get tired of having that fight over and over and let the jerk have their way, if only so they can stop talking about it. Just like with avoiding communicating with a jerk, you can argue that it’s short-sighted to prioritize avoiding a fight right now over dealing with the long term fallout of bad decisions, but you’ll get farther by expecting people to act like people than you will by expecting them to act like emotionless robots.
Finally, why should any non-jerk on your team bother to do their best when you let a jerk get away with writing bad code, refusing to listen to anyone else’s ideas, and making everyone around them feel terrible? If you won’t avoid hiring a jerk for any other reason, do it because all of your devs who can get a better job will do that just so they don’t have to spend all day at work with a jerk. Life is too short to work with jerks!