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

This seems exactly backwards to me.

Disconnecting ego from the work was the first big lesson I had when I started working in software. I hear parallel ideas from friends across industries, in fact an electrical contractor explained to me how he expects it of his apprentices just a few days ago.

I once had a joint software team with a client and put my foot in my mouth assuming they separated code and ego the way we did. The first time I reviewed some of their work, there was a design decision that I sorta assumed was the best of a few bad options. So I asked the developer why they did it that way.

I just wanted to hear some reason, any at all would have done. Something special about that approach, or that they considered the others and found it was, in fact, the least worst. Then we'd just move on, happy enough with our implementation. I'm used to doing that (and having it done to me) dozens of times a month. But what I got was not a defense of the design decision, and more a defense that he made a design decision. I touched a nerve. I now know to hedge, apologize before giving feedback and ask questions by asking around them. I don't really think it's an overall plus. Especially when the business domain puts high standards on us.

I can tell you I haven't had this feeling ever, but not for reasons I'm proud of. I hate doing code reviews. I have hated doing every one. I have disliked having to type every comment I have made on a code review. Each time I hope that everything is good enough and I can just approve it. And I won't comment unless I am convinced it is important.

I don't hate the coder, or the process that requires code reviews. I know code reviews are very important for many different reasons, so I don't shirk them, but I have become afraid of being an expert on a large team as I will have to do more of them. Not sure what is wrong, I love coding. Reviewing good code isn't so bad, reviewing bad code takes all the joy out of coding for me. If it's bad enough, I know that I need to make a lot of comments, and I'll need to make some more when it comes back with changes. I think we are just wired differently.

EDIT After further thought, I think a fundamental difference is I really want to see my coworkers succeed, and don't enjoy their failure. Also I dislike all forms of toil. But I think maybe part of the authors problem is not able to comprehend that some people can be nice like that, genuinely. In fact, I assume my coworkers want me to succeed as well, and I really think most of the time they do. But I am glad he decided to start acting that way, which must be especially difficult if you don't believe others will treat you the same way.

These comments stuck out:

"Because I do code review for self-identification."

and

"It turned out that, instead of becoming a good coder, you simply have to convince others you’re a good coder. This behaviour begets a vicious cycle that produces not professionals, but toxic asshats."

One way to nip this culture is stop hiring people who only KNOW THIS culture.

If the author is reading this, there is one solution I have encountered: diversity. If you only hire white dudes in hoodies with stickers on their macbooks you're only going to get the toxic gamergate crowd, which has not gone away at all.

Believe or not there are other kinds of programmers in the world, and the most enjoyable products I've worked on were ones that had more women and more POC on their teams. Toxic asshattery can be minimized by not giving them complete control over the culture of a workplace.

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.

No, you want to believe you're an alpha male. If you have to keep proving it every day it's not true.

You're acting out because you're insecure as hell and you're trying to prove to yourself that you're an "alpha male". A big part of being secure in your own opinions is letting other people be wrong sometimes.

At some point nothing you can say will stop them. Now you have to switch over to contingency plans. If you're absolutely sure it's going to break if they do it that way, then you need something more constructive than 'I told you so'. People trust you when you pull their fat out of the fire multiple times. Not when you dick wave at them.

> and in a way that I contemplated quitting the industry. I was too dumb for all this.

No, you're not too dumb. You're just wound tighter than a kettle drum. What you need, and I'm being sincere here, is a therapist, not another book on code styles.

We all have our histamine reactions to different things. While you're worried about 5 things someone else is worried about 3 others, one of which you never even thought of. I would hate to be on a team where everyone only cared about exactly the things I care about. My priorities help find issues faster but I don't find them all myself. A team of me would be almost as lopsided as the things I push back against. I try to remind myself that when I'm having trouble with feeling like my #1 priority is someone else's #15 or NaN.

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.

I wish I had a magic blog-post-length formula for how that happened. I don't. I know I personally talk about it in interviews, and we hire for developers who think about development as a team sport rather than a solo FPS rampage, and we talk about code review sort of a lot in onboarding.

The way I explain it to noobs is that a collegial review culture is a question of trust. When we all believe that we are all on the same team with the same goals, we feel safe, and we can trust that (1) critical feedback we receive from others is intended just to improve the code, not to score points on us personally, and (2) if we give feedback that is critical, it will be received in that spirit as well. And it's our responsibility to give critical feedback where the code under review doesn't meet our standards of efficiency, readability, and maintainability.

Grandstanding or mean-spirited reviews break down the team-wide spirit of trust and the feeling of safety; they are a far greater danger to the integrity of the code base than a badly-coded method or spotty test suite.

Presumably, codestyle comes easy for them due to their neurotype, but they have a hard time reining themselves in and just end up wasting thousands of other developers' hours for zero business value.

I've never understood why these people don't just spend a few minutes adding some rules to ESLint or whatever.

However, while this person really feels like an asshole, it's incredibly mature of him to recognize his past behavior and try to improve.

For many developers, it's incredibly satisfying to "be right", and due to the fact that's it's easy to leave some comments, the humanity of their coworkers can often take a backseat.

I can generally differentiate between personal opinion and bad form. I rarely comment on things like variable names, or function names unless they are really confusing or misleading. I have my own style, but the existing style of the code should be what we code based on, not personal opinions.

I think the OP is shirking their responsibilities for what they’re being paid for. If they are doing a code review it’s for the benefit of the team, so that the team member understands what their expectations are. You don’t have to be mean to be a good code reviewer.

Great developers see the opportunity to grow someone.

The former shows ownership of the code, but is generally bad for a business.

The latter understands that a successful business is more than simply his competence.

Reaching this level of realisation is critical for being a good lead; I interview loads of clearly solid programmers who havent figured this out, and sadly price themselves out of the market (I blame their previous managers for missing their growth opportunity)

> No big deal if the code’s not good, I can fix it myself it I need to.

A mentor can't be passive like that. Don't leave 200 comments like you used to, but distill them into something smaller, more cogent and digestible. More importantly, drop the idea of "good" and focus on what the implementor was thinking. I think the author understands the need for more effective communication in code reviews, but unfairly reduces the exchange to an "argument."

It's also dangerous to correlate work-life balance with incompetence. It's not a contradiction to be good at your job, current with the industry, and present for your family.

Many times developers get held to standards that they didn’t know existed. This still triggers developers to feel bad about their work (or themselves). It’s usually after someone has left that they find out some ‘standard’ only exists for that particular company.

It’s hard to make global standards, but company standards are easily do-able without having to endlessly specify every coding situation. What the standard doesn’t cover should be addressed in code review or before.

Sometimes languages come with standards (C# coding standards are better than JavaScript standards, for example) and those can be a good proxy or starting point.

Nobody can read his mind but yet he's expecting rookies to write like veterans.

Typically experienced developers mentor junior developers. If that's not what the author wants to do, then hire only senior developers to not worry about junior mistakes.

Also instead of pointing out all the wrong things, pointing out the good things too are a way to boost the junior developer's motivation.

Humans need face to face contact, because this kind of contact gives you instant feedback about what effect your words and actions are having. It's how most people experience empathy.

I'm one of those who is far better at text communication than face to face due to the luxury of being able to carefully consider my words and their effect rather than having to clumsily do that in real time, but a side effect of this is that my every word gets rewritten multiple times as I try to get the overall tone right, and try to head off potential misunderstandings. My success rate isn't super great, but it's far better than my face to face.

With most people, the opposite seems to be true. Worse: they seem unaware of text communication's shortcomings in terms of the social and emotional feedback loop - empathy. The most toxic people online are often an absolute delight in person, completely oblivious to the damage they're doing because they're empathetically blinded in the other medium, and unaware of the fact.

Because unlike people that think there are right ways I know that it's all religious arguments. Last I checked there are 0 credible reproduced scientific studies about what is the correct way to program. Or even a better way. So as far as I'm concerned it is all opinion based and sure I also have my opinions but, consistency, rule of least power, DRY, agile, OOP, single responsibility principle etc etc are all religious notions.

There are only 2 things that matter: does it work? does it work fast enough?

And normally the arguments boil down to: "Oh but it is not changeable!" - maybe you should make something new "I can't read it!" - I also can't read Chinese "I don't like it" - well not everyone likes chocolate

Wrong on so many levels. Taking pleasure from someone else's mistakes is a sign that something is wrong with you. That is all. The only thing that is exceptional is that this industry has a high tolerance for this behaviour.

It also sounds like this guy is destroying value. If you are such a poor manager that you try to get rid of someone rather than bringing them up then you are a net negative. Again, I have come across this in other industries: the manager will go before the junior. No question. Writing bad code is nothing compared to the impact on culture of one bad apple.

Instead of "Why would you ever do it this way?", try "I think I would probably do this like (example)"

Also, be liberal with complementary reviews, as well. I see a lot of pull requests where the solid, workday, well written code is just passed over, or given a ":+1:", even though it's definitely worthy of praise.

You wrote a new class extracted from an old confusing method, it has good tests, and the feature is working as requested? A triumph.

That said:

> It can’t be open-sourced or used to lure new developers.

This is a mostly unrelated takeaway that I wish more companies followed so that I could take a look at what I'd be working with when they try to recruit me.

I'm 100% like this. I'm not proud of it, and while I guess I can hypothesize about "why", my takeaway is the same as the author's : it's a horrible and potentially very hurtful anti-pattern.

Kudos to this dude for raising his hand and acknowledging his own problem. All I can say is, I'm the same way and I can and should do better.

But you want to look at it like an artifact that you'll later on refer to. Don't be a pedant and ding based on style. If there are substantial design flaws, politely note your concerns, and then hash it out over chat or in person. Your goal is constructive collaboration, and it's really important to use the right collaboration tool for the right job.

Often times, what happens in code reviews is that we find up front design that we neglected to do, or which was done in a way that has structural problems. That's fine -- in fact, the ability to do that incrementally is part of why lean works well. But that means that you've got to then do a proper design session (formal or informal) to get to a better ending place. If you really want to be cooking with gas, figure out a lightweight way to structure and record the results of these design sessions so that people will use and refer to them.

I've seen teams grind to a screeching halt over poor usage of these processes, and not because any of the engineers were poor individual contributors!

I have a done a lot of review not as much lately but my principle is pretty simple - Can this be made better to the best of my understanding and knowledge. I will give it the same attention as I will my code. When my first version of a code or the POC is done I will think of what can be improved upon with the goal of the final version to be cleaner, faster and more robust if possible. My job is to help the author and the company to make sure together we get the best version possible merged of course with an understanding of cost-benefit.

The language is of course important but not catching issues on every line if that's what I find. I will appreciate if someone does the same thing for me. At one point I have reviewed more than 50% of the codes in my company and I know how hard it can be to do so with full care so I take it as a favor when somebody does a good review on my code finds mistakes or potential improvement. I have had way junior developers giving me feedback ranging from better names to serious bugs. I have also always explained why a certain idea should be explored or might be better with the author regardless of how junior they might be. I have always liked the developers best who leaves the ego out of it both a reviewer and author of a certain piece of code. Pride and Ego I find are unrelated. I take pride in giving my best both when writing a code or reviewing one all the while knowing not just that there are other developers much better than me but even someone who is on average worse than me can still find potential improvements in my code. I like to think that I can take any comment on its merit and not my perception of the person.

When I’d justify my decisions they’d go Google and always manage to find a counter point. But their having to Google it made it obvious they lacked deep understanding of much of anything.

There was one guy who was particularly notorious for being harsh and awkward to work with. I found this to be true but he was also the only guy who seemed to understand concepts so I was able to work him (to everyone’s surprise!)

I saw many other developers frequently get a bruising but I always managed to take a step back and focus around the real problem - the people in charge were just angry.

I'd rather have ten mediocre developers who can be part of a team than one gifted diva.

"Greater in battle than the man who would conquer a thousand-thousand men, is he who would conquer just one — himself. Not even a God, an Angel, Mara or Brahma can turn into defeat the victory of a person who is self-subdued and ever restrained in conduct." -- Dhammapada 103-105

My feeling is that criticism, no matter what the domain, should be relatively dispassionate (neutral in tone), and come from a desire to help and with a dose of humility. Of course, I sometimes fall far short of that ideal.

My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that. It’s quite easy, actually.

A bit of irony in the, "It’s quite easy, actually," given the thesis. I can't imagine a harder talent to learn than emotional intelligence. I would rather teach someone...I dunno...concurrent programming than how to stop being an asshole.

People that are really good at things are graceful and helpful usually.

PS-Question: Author mentions Russian culture being an influence. I feel like he's saying there is an emphasis/high value on ultra-competence ultra-stoic unshakability sort of state of being? The meme is that Russians are intense, which I fully respect.

Often code reviews come in after someone has put a few weeks of work into something and its too late to change how it was done. Or a review is passed in by someone in a hurry without actually critiquing it.

If code review breaks software developer's psyche, then this software developer is unlikely to be any good in the first place. How can you be good without ability to listen to code review feedback?

I disagree that pointing out every flaw in a code review is a bad thing to do. I believe that these could be positive experiences with the right attitude from both the reviewer, the submitter, and the team's management. A few things that really bugged me while reading this:

- The reviewer feels like pointing out a flaw is an adversarial zero-sum sort of action that affirms his superiority over the submitter.

- The submitter will feel bad about each feedback given (at least in the POV of the author). If the feedback is mean-spirited, then sure, but if it's constructive, then this shouldn't be the case.

- His team fired the developer who received "too much" feedback. I'm sure there's missing context here, but if that's the main reason, then this is pretty messed up.

Finally, his conclusion to not submit the review really bugged me. I do agree that no review is better than a mean-spirited destructuve review, but IMO this is still a failure on the part of the reviewer. He should write the review in a constructive manner and work with the submitter to hash out the issues. If it's an argument, then fine, work through it... but teammates should help each other grow and be better.

In this case, by not submitting honest and comprehensive reviews, I believe his team and his product suffers in the following ways:

- The reviewer has to waste his time "cleaning up" the code later on.

- The submitter loses out on the knowledge transfer that takes place during a good code review.

- The product potentially has unfixed bugs.

- A fear of conflict is further instilled in the team, and criticism now becomes off-limits because it is considered destructive due to the negative attitudes of everyone involved. This further hurts product quality, and the result is that everyone codes in isolation out of their ivory towers instead of collaborating on a product together, among many other detrimental effects.

I think the solution at least begins with:

- A better team commitment to personal growth, and a sense of responsibility on the part of everyone to help out their teammates in this respect.

- Clear team guidelines on lint/style standards to eliminate the need to argue about it.

- An attitude that feedback is about the code and NOT about the person submitting it. Everyone should feel like an owner of the code, and all discussion should be about the code and how to improve it.

- Comprehensive code reviews. Note everything you find. Maybe call an in-person review if you feel like there's too much to comment on.

edit: typos

I hate this. This always shows a developer whose only idea of a good developer is himself.

Articles complaining about the reality of code reviews seem to be commonplace. But if they're not working out, why not just abandon them, maybe try something different?

Actually, can somebody write that? :P

Change your position to .NET (uppercase). There's no technology called .net (lowercase).

Thank you.

Kudos for saying it aloud though. Honesty is gold (at least in my books).

If your codebase is going to be maintained for a long time, letting sloppy or inconsistent code in is going to make it much harder to maintain or evolve in future, so just lowering standards to make people feel better doesn't work. It's totally reasonable to hold people to a high standard if they're submitting code that others will have to maintain.

A lot of the problem is if people start off with the expectation that their code should be merged with minimal modifications, they're going to be upset when a code reviewer seems to be moving the goalposts on them. Also if the reviewers comments are arbitrary (or seem arbitrary) because they're not obviously grounded in consistent standards.

I've seen a project go through the process of tightening up code review standards and it was initially painful (a lot of people used to the old way feel like they can't move fast enough, etc) but ultimately worked out and resulted in people shipping working features at higher velocity with far less time spent on rework and maintaining overly-complex and buggy code.

There's also way less conflict in onboarding new developers because standards have been made clear in advance and reviewers are expected to be respectful and coach newcomers through the review process.

The hard part, I've found, is working with developers who can't or won't get code to the expected standard, even with coaching and detailed feedback. As in, repeatedly making the same simple mistakes pointed out by reviewers and failing to understand and address relatively straightforward feedback. I'm not sure if there's a solution to this, beyond minimizing the damage and trying to move the person to a role that they're more suited to. In one such instance the person was, in retrospect, a complete liability - they switched to a different team with looser code review, got a "bugfix" committed with some obvious errors that, if not luckily caught by our team, could have potentially had disastrous consequences for some customers, then left the company. Maybe the lesson is that high code review standards contain the damage from such people.

Edit: I also think this requires code reviewers to approach the reviews with the attitude of "what do we have to do to get this merged without compromising our standards?", not a desire to tear down the person or block the code change.

I'm tired of dealing with people like this. It does not have to be this hard. Tech companies should fire more people just for being jerks.

> I was mad that, while I spent my nights learning F#, my daughter started calling everyone around “fathers”.

Huh, you mean missing out on the good parts of life while martyring yourself for a company that does not give a shit about you can lead to resentment and toxic work culture? YOU. DON'T. SAY.

Honestly, a lot of the time management will stoke the "hero coders" ego so they will do the free work.

Management: Oh, Hero Protagonist! We need you! How will we ever earn enough to give our CEO the 15 million bonus if you do not martyr yourself for this feature?

Hero Protagonist: They're right. I am the best and smartest. I better dump all of my emotional labor onto my coworkers and significant others and bury myself into doing free work for my company.

> When you work as a developer, you always have to argue. You, as a team, arrive on a solution after a lot of argument, even though we call them “discussions”.

I do not feel this way at all. There are productive ways to have discussions that do not involve getting defensive and arguing.

The fact that you have to drag all of your discussions into toxic arguments in order to save face is... sad.

> And yet it’s somehow important than your arguments “win” more often than not, just to feel good and confident in your power.

No, it is not. That is just how you feel to justify your constant toxicity.

I see very little "power" in bullying all of the other developers on my team into following my opinions.

Are you kidding? Call me a liar if you want, but I don't feel that way when doing code reviews, and never have.

Yes, when I was a teenager I wielded my knowledge like a titan. The meager amount of knowledge I had.

But as a professional, I have never once been mean-spirited in a code review. Everything I send back is to keep the code clean and maintainable and to help the developer improve.

Not everyone feels the need to be "right" all the time. And by that, I mean being perceived as correct, even if they aren't. For me, that was a function of actual skill.

The better I got at programming, the less I needed everyone else to acknowledge how good I was.

Even better, that applied to the rest of my life, too. I haven't felt the need to show off my intelligence or skills in a long, long time. I simply do my thing and if/when someone notices, it's a great feeling. If they don't, I still enjoyed doing it well.

I try to view code review as my chance to pass this on. It's about teaching someone how to read their own code with a critical mind. It's definitely not about superlatives like best, perfect, whatever.

A lot of elitism comes from going through a high level of discipline for no reward.

Just do what is fulfilling

We recently managed to get rid of someone that wasa this sure of himself that he had the impression that he carried the team.

While his technical skill was sound (though no better than any halfway-decent senior developer) the reality was he was a poor communicator, kept knowledge to himself, posted snarky comments on reviews and cast apersions on everybody else's skills.

He was an egomaniac and the team has fared much better without him.

If you ever find yourself with a team member like the author of this blog post, be mindful of the damage they can cause because of their own inflated sense of self-worth.