[tpmoney]

Two things I try to do in every code review:

If I’m doing the review, I try to find at least one or two items to call out as great ideas/moves. Even if it’s as simple as refactoring a minor pain point.

If I’m being reviewed I always make sure to thank/compliment comments that either suggest something I genuinely didn’t consider or catch a dumb move that isn’t wrong but would be a minor pain point in the future.

As you note, code reviews can be largely “negative feedback” systems, and I find encouraging even a small amount of positivity in the process keeps it from becoming soul sucking

[hackpelican]

In some companies, (ahem… Amazon), engineers are judged by their code review/comment ratio. Especially L4 engineers trying to make it to L5.

So actually putting positive comments in the code review isn’t really much appreciated.

I gained this habit and now for me, a comment is a suggestion of improvement, I deliver praise out-of-band.

[wavemode]

> engineers are judged by their code review/comment ratio

It's a horrible practice with adverse incentives, and one of the reasons I'm glad I no longer work there

(and easily gameable, anyways - people would just DM each other patches they were unsure of, before submitting an actual CR)

[tpmoney]

The more I learn about how the bigger companies do business, the happier I am my dreams of working for them never materialized. I encounter enough stupid things caused by businesses trying to measure difficult things. I would hate to work in a place where the proper mode of conduct – praise in public, criticize in private – is flipped on its head for the purposes of someone's spreadsheet.

[hackpelican]

It was definitely a bad system that leads to wrong incentives.

Due to this, a lot of the time, leaving a comment would lead to friction with the owner of the CR, thus disincentivizing leaving comments, which leads to worse code being merged.