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

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.

> This review I kicked off the article with? I didn’t send it. Instead I gave the guy a couple of comments and politely asked to fix a couple of things. No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.

> 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.

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.

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.