Comment by atq2119

2 days ago

See also: code review

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

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

    • > 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)

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