I ruin developers’ lives with my code reviews and I'm sorry

We had a guy at a previous job who was a toxic douchebag, not radically different than the guy describing himself here (doing F# too, actually, which I found to be a funny coincidence).

The guy was undeniably brilliant, pretty clearly smarter than anyone else on the team (including me), but he had a way of bringing down the entire team to a point where it actually felt like we were less productive a result. After about a year of this, he was fired.

Ironically after he was fired he and I became pretty good friends, and I feel that, at some level, I became the new toxic douchebag with my (probably unearned) feelings of superiority. When I realized this, I actively tried to employ a bit more empathy when looking at code reviews and dealing with people that I felt were stupid, since I was the "stupid" one before.

I often discuss with people the philosophical question of "is it better to have someone who's really smart but also an asshole, or someone very nice who's barely competent?". I tend to lean towards the former, but I can't say for sure.

As a professional, I got tired of being mean, so I switched to a different review style where I ask questions instead. I would still ask a lot of questions.

Then I started to worry that I was coming across as passive-aggressive, that these suggestions would be taken as veiled demands to fix things.

As a countermeasure, sometimes I'd explicitly say things like, "you can submit this as-is, but here are a bunch of things you might want to think about." This works ok for stylistic changes or things that aren't actual bugs.

That's not always realistic. Another trick that I think maybe we should do more in the industry is what I'd call ping-pong code review: When you get a review, either submit it if it's good enough, or rewrite it and send it back to them for review. Then they can either submit it, or do another rewrite and send it back to you.

This helps the most if there extensive changes needed, and you are a picky person who likes to have things just right. But, if it goes against company culture, you might need to make sure that people understand what you're doing and everyone gets proper credit for helping with the patch.

Consistency of code style does matter, up to a point, to people reading and understanding the code. As you suggest, setting up ground rules and tooling helps

Code authors who don't see the value in consistency of code are potentially a problem - if authors are submitting code reviews with hundreds of actual style issues, that's either a failure of process or the author to write readable code (not sure if that's what happened in your examples, to be clear).

The author is talking about a learning experience he had regarding a deficiency he identified (being a jerk) in his own work (reviewing other coders' code).

Meanwhile, your comment levies personal criticism toward him using pretty inflammatory language ("toxic," "sad," "asshole," "jerk," etc.), because of the way he responds to people who are learning.

Interesting juxtaposition, that.

I can't say I enjoyed code reviewing but I never felt like I was being mean to my teammates. I was really happy when a teammate found a bug in code review of my code rather than that bug getting checked in. I was also really happy when they shared knowledge and I learned something. Maybe they shared a pattern I was unfamiliar with or maybe they pointed out an existing function I could use I didn't know was in the code.

I assumed the same was true for them. I learned from another team member to try to phrase comments as questions. "Did you mean to do X here? It seems like it might have issue Y" etc...